Skip to content
Snippets Groups Projects
  1. May 01, 2019
  2. Apr 29, 2019
  3. Apr 19, 2019
  4. Apr 18, 2019
    • YueHaibing's avatar
      sched/core: Make some functions static · b1546edc
      YueHaibing authored
      
      Fix these sparse warnings:
      
        kernel/sched/core.c:6577:11: warning: symbol 'min_cfs_quota_period' was not declared. Should it be static?
        kernel/sched/core.c:6657:5: warning: symbol 'tg_set_cfs_quota' was not declared. Should it be static?
        kernel/sched/core.c:6670:6: warning: symbol 'tg_get_cfs_quota' was not declared. Should it be static?
        kernel/sched/core.c:6683:5: warning: symbol 'tg_set_cfs_period' was not declared. Should it be static?
        kernel/sched/core.c:6693:6: warning: symbol 'tg_get_cfs_period' was not declared. Should it be static?
        kernel/sched/fair.c:2596:6: warning: symbol 'task_tick_numa' was not declared. Should it be static?
      
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20190418144713.34332-1-yuehaibing@huawei.com
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      b1546edc
  5. Apr 16, 2019
  6. Apr 10, 2019
    • Valentin Schneider's avatar
      sched/topology: Skip duplicate group rewrites in build_sched_groups() · 67d4f6ff
      Valentin Schneider authored
      
      While staring at build_sched_domains(), I realized that get_group()
      does several duplicate (thus useless) writes.
      
      If you take the Arm Juno r0 (LITTLEs = [0, 3, 4, 5], bigs = [1, 2]), the
      sched_group build flow would look like this:
      
      ('MC[cpu]->sg' means 'per_cpu_ptr(&tl->data->sg, cpu)' with 'tl == MC')
      
      build_sched_groups(MC[CPU0]->sd, CPU0)
        get_group(0) -> MC[CPU0]->sg
        get_group(3) -> MC[CPU3]->sg
        get_group(4) -> MC[CPU4]->sg
        get_group(5) -> MC[CPU5]->sg
      
      build_sched_groups(DIE[CPU0]->sd, CPU0)
        get_group(0) -> DIE[CPU0]->sg
        get_group(1) -> DIE[CPU1]->sg <=================+
      						  |
      build_sched_groups(MC[CPU1]->sd, CPU1)            |
        get_group(1) -> MC[CPU1]->sg                    |
        get_group(2) -> MC[CPU2]->sg                    |
      						  |
      build_sched_groups(DIE[CPU1]->sd, CPU1)           ^
        get_group(1) -> DIE[CPU1]->sg  } We've set up these two up here!
        get_group(3) -> DIE[CPU0]->sg  }
      
      From this point on, we will only use sched_groups that have been
      previously visited & initialized. The only new operation will
      be which group pointer we affect to sd->groups.
      
      On the Juno r0 we get 32 get_group() calls, every single one of them
      writing to a sched_group->cpumask. However, all of the data structures
      we need are set up after 8 visits (see above).
      
      Return early from get_group() if we've already visited (and thus
      initialized) the sched_group we're looking at. Overlapping domains
      are not affected as they do not use build_sched_groups().
      
      Tested on a Juno and a 2 * (Xeon E5-2690) system.
      
      ( FWIW I initially checked the refs for both sg && sg->sgc, but figured if
        they weren't both 0 or > 1 then something must have gone wrong, so I
        threw in a WARN_ON(). )
      
      No change in functionality intended.
      
      Signed-off-by: default avatarValentin Schneider <valentin.schneider@arm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      67d4f6ff
    • Valentin Schneider's avatar
      sched/topology: Fix build_sched_groups() comment · d8743230
      Valentin Schneider authored
      The comment was introduced (pre 2.6.12) by:
      
        8a7a2318dc07 ("[PATCH] sched: consolidate sched domains")
      
      and referred to sched_group->cpu_power. This was folded into
      sched_group->sched_group_power in
      
        commit 9c3f75cb ("sched: Break out cpu_power from the sched_group structure")
      
      The comment was then updated in:
      
        ced549fa
      
       ("sched: Remove remaining dubious usage of "power"")
      
      but should have replaced "sg->cpu_capacity" with
      "sg->sched_group_capacity". Do that now.
      
      Signed-off-by: default avatarValentin Schneider <valentin.schneider@arm.com>
      Cc: Dietmar.Eggemann@arm.com
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: morten.rasmussen@arm.com
      Cc: qais.yousef@arm.com
      Link: http://lkml.kernel.org/r/20190409173546.4747-3-valentin.schneider@arm.com
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d8743230
  7. Apr 03, 2019
    • YueHaibing's avatar
      sched/fair: Make sync_entity_load_avg() and remove_entity_load_avg() static · 71b47eaf
      YueHaibing authored
      
      Fix these sparse warnigs:
      
        kernel/sched/fair.c:3570:6: warning: symbol 'sync_entity_load_avg' was not declared. Should it be static?
        kernel/sched/fair.c:3583:6: warning: symbol 'remove_entity_load_avg' was not declared. Should it be static?
      
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20190320133839.21392-1-yuehaibing@huawei.com
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      71b47eaf
    • Joel Fernandes (Google)'s avatar
      sched/core: Annotate perf_domain pointer with __rcu · 7ba7319f
      Joel Fernandes (Google) authored
      
      This fixes the following sparse errors in sched/fair.c:
      
        fair.c:6506:14: error: incompatible types in comparison expression
        fair.c:8642:21: error: incompatible types in comparison expression
      
      Using __rcu will also help sparse catch any future bugs.
      
      Signed-off-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      [ From an RCU perspective. ]
      Reviewed-by: default avatarPaul E. McKenney <paulmck@linux.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Lai Jiangshan <jiangshanlai@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Morten Rasmussen <morten.rasmussen@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: keescook@chromium.org
      Cc: kernel-hardening@lists.openwall.com
      Cc: kernel-team@android.com
      Link: https://lkml.kernel.org/r/20190321003426.160260-5-joel@joelfernandes.org
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7ba7319f
    • Joel Fernandes (Google)'s avatar
      rcuwait: Annotate task_struct with __rcu · 03f4b48e
      Joel Fernandes (Google) authored
      
      This suppresses sparse error generated due to the recently added
      rcu_assign_pointer sparse check.
      
        percpu-rwsem.c:162:9: sparse: error: incompatible types in comparison expression
        exit.c:316:16: sparse: error: incompatible types in comparison expression
      
      Signed-off-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      [ From an RCU perspective. ]
      Reviewed-by: default avatarPaul E. McKenney <paulmck@linux.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Lai Jiangshan <jiangshanlai@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Morten Rasmussen <morten.rasmussen@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: keescook@chromium.org
      Cc: kernel-hardening@lists.openwall...
      03f4b48e
    • Joel Fernandes (Google)'s avatar
      sched_domain: Annotate RCU pointers properly · 994aeb7a
      Joel Fernandes (Google) authored
      
      The scheduler uses RCU API in various places to access sched_domain
      pointers. These cause sparse errors as below.
      
      Many new errors show up because of an annotation check I added to
      rcu_assign_pointer(). Let us annotate the pointers correctly which also
      will help sparse catch any potential future bugs.
      
      This fixes the following sparse errors:
      
        rt.c:1681:9: error: incompatible types in comparison expression
        deadline.c:1904:9: error: incompatible types in comparison expression
        core.c:519:9: error: incompatible types in comparison expression
        core.c:1634:17: error: incompatible types in comparison expression
        fair.c:6193:14: error: incompatible types in comparison expression
        fair.c:9883:22: error: incompatible types in comparison expression
        fair.c:9897:9: error: incompatible types in comparison expression
        sched.h:1287:9: error: incompatible types in comparison expression
        topology.c:612:9: error: incompatible types in comparison expression
        topology.c:615:9: error: incompatible types in comparison expression
        sched.h:1300:9: error: incompatible types in comparison expression
        topology.c:618:9: error: incompatible types in comparison expression
        sched.h:1287:9: error: incompatible types in comparison expression
        topology.c:621:9: error: incompatible types in comparison expression
        sched.h:1300:9: error: incompatible types in comparison expression
        topology.c:624:9: error: incompatible types in comparison expression
        topology.c:671:9: error: incompatible types in comparison expression
        stats.c:45:17: error: incompatible types in comparison expression
        fair.c:5998:15: error: incompatible types in comparison expression
        fair.c:5989:15: error: incompatible types in comparison expression
        fair.c:5998:15: error: incompatible types in comparison expression
        fair.c:5989:15: error: incompatible types in comparison expression
        fair.c:6120:19: error: incompatible types in comparison expression
        fair.c:6506:14: error: incompatible types in comparison expression
        fair.c:6515:14: error: incompatible types in comparison expression
        fair.c:6623:9: error: incompatible types in comparison expression
        fair.c:5970:17: error: incompatible types in comparison expression
        fair.c:8642:21: error: incompatible types in comparison expression
        fair.c:9253:9: error: incompatible types in comparison expression
        fair.c:9331:9: error: incompatible types in comparison expression
        fair.c:9519:15: error: incompatible types in comparison expression
        fair.c:9533:14: error: incompatible types in comparison expression
        fair.c:9542:14: error: incompatible types in comparison expression
        fair.c:9567:14: error: incompatible types in comparison expression
        fair.c:9597:14: error: incompatible types in comparison expression
        fair.c:9421:16: error: incompatible types in comparison expression
        fair.c:9421:16: error: incompatible types in comparison expression
      
      Signed-off-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      [ From an RCU perspective. ]
      Reviewed-by: default avatarPaul E. McKenney <paulmck@linux.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Lai Jiangshan <jiangshanlai@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Morten Rasmussen <morten.rasmussen@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: keescook@chromium.org
      Cc: kernel-hardening@lists.openwall.com
      Cc: kernel-team@android.com
      Link: https://lkml.kernel.org/r/20190321003426.160260-3-joel@joelfernandes.org
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      994aeb7a
    • Joel Fernandes (Google)'s avatar
      sched/cpufreq: Annotate cpufreq_update_util_data pointer with __rcu · b10abd0a
      Joel Fernandes (Google) authored
      
      Recently I added an RCU annotation check to rcu_assign_pointer(). All
      pointers assigned to RCU protected data are to be annotated with __rcu
      inorder to be able to use rcu_assign_pointer() similar to checks in
      other RCU APIs.
      
      This resulted in a sparse error:
      
        kernel//sched/cpufreq.c:41:9: sparse: error: incompatible types in comparison expression (different address spaces)
      
      Fix this by annotating cpufreq_update_util_data pointer with __rcu. This
      will also help sparse catch any future RCU misuage bugs.
      
      Signed-off-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      [ From an RCU perspective. ]
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: default avatarPaul E. McKenney <paulmck@linux.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Lai Jiangshan <jiangshanlai@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Morten Rasmussen <morten.rasmussen@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: keescook@chromium.org
      Cc: kernel-hardening@lists.openwall.com
      Cc: kernel-team@android.com
      Link: https://lkml.kernel.org/r/20190321003426.160260-2-joel@joelfernandes.org
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      b10abd0a
    • Mel Gorman's avatar
      sched/fair: Do not re-read ->h_load_next during hierarchical load calculation · 0e9f0245
      Mel Gorman authored
      
      A NULL pointer dereference bug was reported on a distribution kernel but
      the same issue should be present on mainline kernel. It occured on s390
      but should not be arch-specific.  A partial oops looks like:
      
        Unable to handle kernel pointer dereference in virtual kernel address space
        ...
        Call Trace:
          ...
          try_to_wake_up+0xfc/0x450
          vhost_poll_wakeup+0x3a/0x50 [vhost]
          __wake_up_common+0xbc/0x178
          __wake_up_common_lock+0x9e/0x160
          __wake_up_sync_key+0x4e/0x60
          sock_def_readable+0x5e/0x98
      
      The bug hits any time between 1 hour to 3 days. The dereference occurs
      in update_cfs_rq_h_load when accumulating h_load. The problem is that
      cfq_rq->h_load_next is not protected by any locking and can be updated
      by parallel calls to task_h_load. Depending on the compiler, code may be
      generated that re-reads cfq_rq->h_load_next after the check for NULL and
      then oops when reading se->avg.load_avg. The dissassembly showed that it
      was possible to reread h_load_next after the check for NULL.
      
      While this does not appear to be an issue for later compilers, it's still
      an accident if the correct code is generated. Full locking in this path
      would have high overhead so this patch uses READ_ONCE to read h_load_next
      only once and check for NULL before dereferencing. It was confirmed that
      there were no further oops after 10 days of testing.
      
      As Peter pointed out, it is also necessary to use WRITE_ONCE() to avoid any
      potential problems with store tearing.
      
      Signed-off-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: default avatarValentin Schneider <valentin.schneider@arm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: <stable@vger.kernel.org>
      Fixes: 68520796 ("sched: Move h_load calculation to task_h_load()")
      Link: https://lkml.kernel.org/r/20190319123610.nsivgf3mjbjjesxb@techsingularity.net
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      0e9f0245