lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 24 Nov 2010 01:31:13 +0100 From: Frederic Weisbecker <fweisbec@...il.com> To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> Cc: LKML <linux-kernel@...r.kernel.org>, Frederic Weisbecker <fweisbec@...il.com>, "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, Lai Jiangshan <laijs@...fujitsu.com>, Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Steven Rostedt <rostedt@...dmis.org> Subject: [PATCH 2/2] rcu: Stop checking quiescent states after grace period completion from remote After a CPU starts to chase its quiescent states by setting rdp->qs_pending to 1, it can still enter into an extended quiescent state and then another CPU will take care of this and complete the grace period if necessary. rcu_report_qs_rdp() currently doesn't handle well this case and considers it must try later to notify its quiescent state. However if the last grace period has been completed there is nothing left to do for the current CPU. It means that until a next grace period starts, the CPU that runs into that case will keep chasing its own quiescent states by raising a softirq on every tick for no good reason. This can take a while before a new grace period starts and this time slice is covered by spurious softirqs and other kinds of rcu checks. Fix this by resetting rdp->qs_pending if the last grace period has been completed by a remote CPU while we were in an extended quiescent state. Signed-off-by: Frederic Weisbecker <fweisbec@...il.com> Cc: Paul E. McKenney <paulmck@...ux.vnet.ibm.com> Cc: Lai Jiangshan <laijs@...fujitsu.com> Cc: Ingo Molnar <mingo@...e.hu> Cc: Thomas Gleixner <tglx@...utronix.de> Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl> Cc: Steven Rostedt <rostedt@...dmis.org> --- kernel/rcutree.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/kernel/rcutree.c b/kernel/rcutree.c index 5f038a1..f287eaa 100644 --- a/kernel/rcutree.c +++ b/kernel/rcutree.c @@ -937,6 +937,15 @@ rcu_report_qs_rdp(int cpu, struct rcu_state *rsp, struct rcu_data *rdp, long las * race occurred. */ rdp->passed_quiesc = 0; /* try again later! */ + + /* + * Another CPU may have taken care of us if we were in an + * extended quiescent state, in which case we don't need + * to continue to track anything. + */ + if (rnp->gpnum == rnp->completed) + rdp->qs_pending = 0; + raw_spin_unlock_irqrestore(&rnp->lock, flags); return; } -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists