1. 16 5月, 2018 1 次提交
    • P
      rcu: Rename cond_resched_rcu_qs() to cond_resched_tasks_rcu_qs() · cee43939
      Paul E. McKenney 提交于
      Commit e31d28b6 ("trace: Eliminate cond_resched_rcu_qs() in favor
      of cond_resched()") substituted cond_resched() for the earlier call
      to cond_resched_rcu_qs().  However, the new-age cond_resched() does
      not do anything to help RCU-tasks grace periods because (1) RCU-tasks
      is only enabled when CONFIG_PREEMPT=y and (2) cond_resched() is a
      complete no-op when preemption is enabled.  This situation results
      in hangs when running the trace benchmarks.
      
      A number of potential fixes were discussed on LKML
      (https://lkml.kernel.org/r/20180224151240.0d63a059@vmware.local.home),
      including making cond_resched() not be a no-op; making cond_resched()
      not be a no-op, but only when running tracing benchmarks; reverting
      the aforementioned commit (which works because cond_resched_rcu_qs()
      does provide an RCU-tasks quiescent state; and adding a call to the
      scheduler/RCU rcu_note_voluntary_context_switch() function.  All were
      deemed unsatisfactory, either due to added cond_resched() overhead or
      due to magic functions inviting cargo culting.
      
      This commit renames cond_resched_rcu_qs() to cond_resched_tasks_rcu_qs(),
      which provides a clear hint as to what this function is doing and
      why and where it should be used, and then replaces the call to
      cond_resched() with cond_resched_tasks_rcu_qs() in the trace benchmark's
      benchmark_event_kthread() function.
      Reported-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Tested-by: NNicholas Piggin <npiggin@gmail.com>
      cee43939
  2. 24 2月, 2018 1 次提交
    • P
      rcu: Create RCU-specific workqueues with rescuers · ad7c946b
      Paul E. McKenney 提交于
      RCU's expedited grace periods can participate in out-of-memory deadlocks
      due to all available system_wq kthreads being blocked and there not being
      memory available to create more.  This commit prevents such deadlocks
      by allocating an RCU-specific workqueue_struct at early boot time, and
      providing it with a rescuer to ensure forward progress.  This uses the
      shiny new init_rescuer() function provided by Tejun (but indirectly).
      
      This commit also causes SRCU to use this new RCU-specific
      workqueue_struct.  Note that SRCU's use of workqueues never blocks them
      waiting for readers, so this should be safe from a forward-progress
      viewpoint.  Note that this moves SRCU from system_power_efficient_wq
      to a normal workqueue.  In the unlikely event that this results in
      measurable degradation, a separate power-efficient workqueue will be
      creates for SRCU.
      Reported-by: NPrateek Sood <prsood@codeaurora.org>
      Reported-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      ad7c946b
  3. 21 2月, 2018 5 次提交
  4. 16 2月, 2018 1 次提交
  5. 12 12月, 2017 1 次提交
  6. 29 11月, 2017 8 次提交
  7. 28 11月, 2017 7 次提交
  8. 08 11月, 2017 1 次提交
  9. 20 10月, 2017 2 次提交
  10. 10 10月, 2017 2 次提交
    • P
      rcu: Make RCU CPU stall warnings check for irq-disabled CPUs · 9b9500da
      Paul E. McKenney 提交于
      One common question upon seeing an RCU CPU stall warning is "did
      the stalled CPUs have interrupts disabled?"  However, the current
      stall warnings are silent on this point.  This commit therefore
      uses irq_work to check whether stalled CPUs still respond to IPIs,
      and flags this state in the RCU CPU stall warning console messages.
      Reported-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      9b9500da
    • P
      sched,rcu: Make cond_resched() provide RCU quiescent state · f79c3ad6
      Paul E. McKenney 提交于
      There is some confusion as to which of cond_resched() or
      cond_resched_rcu_qs() should be added to long in-kernel loops.
      This commit therefore eliminates the decision by adding RCU quiescent
      states to cond_resched().  This commit also simplifies the code that
      used to interact with cond_resched_rcu_qs(), and that now interacts with
      cond_resched(), to reduce its overhead.  This reduction is necessary to
      allow the heavier-weight cond_resched_rcu_qs() mechanism to be invoked
      everywhere that cond_resched() is invoked.
      
      Part of that reduction in overhead converts the jiffies_till_sched_qs
      kernel parameter to read-only at runtime, thus eliminating the need for
      bounds checking.
      Reported-by: NMichal Hocko <mhocko@kernel.org>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      [ paulmck: Keep PREEMPT=n cond_resched a no-op, per Peter Zijlstra. ]
      f79c3ad6
  11. 03 10月, 2017 1 次提交
  12. 24 9月, 2017 1 次提交
    • P
      rcu: Allow for page faults in NMI handlers · 28585a83
      Paul E. McKenney 提交于
      A number of architecture invoke rcu_irq_enter() on exception entry in
      order to allow RCU read-side critical sections in the exception handler
      when the exception is from an idle or nohz_full CPU.  This works, at
      least unless the exception happens in an NMI handler.  In that case,
      rcu_nmi_enter() would already have exited the extended quiescent state,
      which would mean that rcu_irq_enter() would (incorrectly) cause RCU
      to think that it is again in an extended quiescent state.  This will
      in turn result in lockdep splats in response to later RCU read-side
      critical sections.
      
      This commit therefore causes rcu_irq_enter() and rcu_irq_exit() to
      take no action if there is an rcu_nmi_enter() in effect, thus avoiding
      the unscheduled return to RCU quiescent state.  This in turn should
      make the kernel safe for on-demand RCU voyeurism.
      
      Link: http://lkml.kernel.org/r/20170922211022.GA18084@linux.vnet.ibm.com
      
      Cc: stable@vger.kernel.org
      Fixes: 0be964be ("module: Sanitize RCU usage and locking")
      Reported-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      28585a83
  13. 09 9月, 2017 1 次提交
  14. 17 8月, 2017 7 次提交
  15. 26 7月, 2017 1 次提交
    • P
      rcu: Move callback-list warning to irq-disable region · 09efeeee
      Paul E. McKenney 提交于
      After adopting callbacks from a newly offlined CPU, the adopting CPU
      checks to make sure that its callback list's count is zero only if the
      list has no callbacks and vice versa.  Unfortunately, it does so after
      enabling interrupts, which means that false positives are possible due to
      interrupt handlers invoking call_rcu().  Although these false positives
      are improbable, rcutorture did make it happen once.
      
      This commit therefore moves this check to an irq-disabled region of code,
      thus suppressing the false positive.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      09efeeee