[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170921160048.GI3521@linux.vnet.ibm.com>
Date: Thu, 21 Sep 2017 09:00:48 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Neeraj Upadhyay <neeraju@...eaurora.org>,
josh@...htriplett.org, mathieu.desnoyers@...icios.com,
jiangshanlai@...il.com, linux-kernel@...r.kernel.org,
sramana@...eaurora.org, prsood@...eaurora.org,
pkondeti@...eaurora.org, markivx@...eaurora.org
Subject: Re: Query regarding synchronize_sched_expedited and resched_cpu
On Thu, Sep 21, 2017 at 03:59:46PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 19, 2017 at 08:31:26AM -0700, Paul E. McKenney wrote:
> > So I have this one queued. Objections?
>
> Changelog reads like its whitespace damaged.
It does, now that you mention it. How about the updated version below?
Thanx, Paul
------------------------------------------------------------------------
commit c21c9b78182e35eb0e72ef4e3bba3054f26eaaea
Author: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
Date: Mon Sep 18 08:54:40 2017 -0700
sched: Make resched_cpu() unconditional
The current implementation of synchronize_sched_expedited() incorrectly
assumes that resched_cpu() is unconditional, which it is not. This means
that synchronize_sched_expedited() can hang when resched_cpu()'s trylock
fails as follows (analysis by Neeraj Upadhyay):
o CPU1 is waiting for expedited wait to complete:
sync_rcu_exp_select_cpus
rdp->exp_dynticks_snap & 0x1 // returns 1 for CPU5
IPI sent to CPU5
synchronize_sched_expedited_wait
ret = swait_event_timeout(rsp->expedited_wq,
sync_rcu_preempt_exp_done(rnp_root),
jiffies_stall);
expmask = 0x20, CPU 5 in idle path (in cpuidle_enter())
o CPU5 handles IPI and fails to acquire rq lock.
Handles IPI
sync_sched_exp_handler
resched_cpu
returns while failing to try lock acquire rq->lock
need_resched is not set
o CPU5 calls rcu_idle_enter() and as need_resched is not set, goes to
idle (schedule() is not called).
o CPU 1 reports RCU stall.
Given that resched_cpu() is now used only by RCU, this commit fixes the
assumption by making resched_cpu() unconditional.
Reported-by: Neeraj Upadhyay <neeraju@...eaurora.org>
Suggested-by: Neeraj Upadhyay <neeraju@...eaurora.org>
Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@...radead.org>
Acked-by: Steven Rostedt (VMware) <rostedt@...dmis.org>
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index cab8c5ec128e..b2281971894c 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -505,8 +505,7 @@ void resched_cpu(int cpu)
struct rq *rq = cpu_rq(cpu);
unsigned long flags;
- if (!raw_spin_trylock_irqsave(&rq->lock, flags))
- return;
+ raw_spin_lock_irqsave(&rq->lock, flags);
resched_curr(rq);
raw_spin_unlock_irqrestore(&rq->lock, flags);
}
Powered by blists - more mailing lists