Re: rhashtable: hang while running tests on boot

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Sat, Oct 11, 2014 at 08:41:26AM -0400, Sasha Levin wrote:
> On 10/10/2014 10:22 AM, Paul E. McKenney wrote:
> > I am guessing that this happens only when running the resizable hashtable
> > tests -- if that guess is incorrect, please let me know.
> 
> Paul, I'm not sure if it's related or not - but I'm also seeing quite a few
> unexplainable (read: which I can't explain) RCU stalls:
> 
> [ 2121.852211] INFO: rcu_preempt detected stalls on CPUs/tasks:
> [ 2121.852233]  0: (244 ticks this GP) idle=1f7/140000000000002/0 softirq=18045/18045 last_accelerate: 7794/c7aa, nonlazy_posted: 576737, ..
> [ 2121.852260]  (detected by 7, t=20502 jiffies, g=16439, c=16438, q=63119)
> [ 2121.852265] Task dump for CPU 0:
> [ 2121.852294] ksoftirqd/0     R  running task    13504     3      2 0x10080008
> [ 2121.852307]  ffff880068203d88 ffffffff8efe9a34 ffff880068203d48 0000000000000000
> [ 2121.852317]  ffff8800681c3000 ffff880068200010 ffff880068200000 000001bae312d5a9
> [ 2121.852327]  ffff880064a5b000 ffff880064a5b000 ffff880068203d78 0000000000000000
> [ 2121.852330] Call Trace:
> [ 2121.852354]  [<ffffffff8efe9a34>] ? __schedule+0x614/0xdd0
> [ 2121.852364]  [<ffffffff8efea230>] schedule+0x40/0xb0
> [ 2121.852378]  [<ffffffff8a1fe4a8>] smpboot_thread_fn+0x1b8/0x420
> [ 2121.852389]  [<ffffffff8a1c7a90>] ? tasklet_init+0x70/0x70
> [ 2121.852399]  [<ffffffff8a1fe2f0>] ? SyS_setgroups+0x1e0/0x1e0
> [ 2121.852410]  [<ffffffff8a1f7aa4>] kthread+0x144/0x170
> [ 2121.852420]  [<ffffffff8efec2cf>] ? wait_for_completion+0x10f/0x160
> [ 2121.852431]  [<ffffffff8a1f7960>] ? flush_kthread_work+0x1d0/0x1d0
> [ 2121.852440]  [<ffffffff8eff4a3c>] ret_from_fork+0x7c/0xb0
> [ 2121.852450]  [<ffffffff8a1f7960>] ? flush_kthread_work+0x1d0/0x1d0

Does the following patch help?  (If you kernel does not have a
rcu_note_voluntary_context_switch(), replace this with
rcu_note_context_switch().)

							Thanx, Paul

------------------------------------------------------------------------

workqueue: Add quiescent state between work items

Similar to the stop_machine deadlock scenario on !PREEMPT kernels
addressed in b22ce2785d97 "workqueue: cond_resched() after processing
each work item", kworker threads requeueing back-to-back with zero jiffy
delay can stall RCU. The cond_resched call introduced in that fix will
yield only iff there are other higher priority tasks to run, so force a
quiescent RCU state between work items.

Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com>
Link: https://lkml.kernel.org/r/20140926105227.01325697@jlaw-desktop.mno.stratus.com
Link: https://lkml.kernel.org/r/20140929115445.40221d8e@jlaw-desktop.mno.stratus.com
Fixes: b22ce2785d97 ("workqueue: cond_resched() after processing each work item")
Cc: <stable@vger.kernel.org>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 5dbe22aa3efd..345bec95e708 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -2043,8 +2043,10 @@ __acquires(&pool->lock)
 	 * kernels, where a requeueing work item waiting for something to
 	 * happen could deadlock with stop_machine as such work item could
 	 * indefinitely requeue itself while all other CPUs are trapped in
-	 * stop_machine.
+	 * stop_machine. At the same time, report a quiescent RCU state so
+	 * the same condition doesn't freeze RCU.
 	 */
+	rcu_note_voluntary_context_switch(current);
 	cond_resched();
 
 	spin_lock_irq(&pool->lock);