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: Tue, 8 Aug 2017 14:56:13 -0700 From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> To: Neeraj Upadhyay <neeraju@...eaurora.org> Cc: josh@...htriplett.org, rostedt@...dmis.org, mathieu.desnoyers@...icios.com, jiangshanlai@...il.com, linux-kernel@...r.kernel.org Subject: Re: [PATCH] rcu: Skip additional checks if rcu_cpu_stall_suppress is set On Wed, Aug 09, 2017 at 12:27:16AM +0530, Neeraj Upadhyay wrote: > > > On 08/08/2017 11:32 PM, Paul E. McKenney wrote: > >On Tue, Aug 08, 2017 at 10:50:26PM +0530, Neeraj Upadhyay wrote: > >>If rcu_kick_kthreads is set, and gp is in progress, check_cpu_stall() > >>does checks to figure out whether jiffies is past rsp->jiffies_stall, > >>doing ordered accesses to avoid any false positives for new grace > >>period initialization after a sufficiently large idle period. This > >>extra processing can be skipped if rcu_cpu_stall_suppress is set. > >Just to make sure I understand, the concern is that someone might have > >booted with rcupdate.rcu_cpu_stall_suppress=1 (thus suppressing the RCU > >CPU stall debugging warnings implemented later in check_cpu_stall()), > >but later decided to also boot with rcutree.rcu_kick_kthreads=1 (thus > >enabling kicking kthreads which check for RCU's grace-period kthreads > >not being properly awakened)? > > > >My immediate reaction is that if there is not much point in specifying > >both rcutree.rcu_kick_kthreads=1 and rcupdate.rcu_cpu_stall_suppress=1. > >But is there some use case that I am missing? > > > > Thanx, Paul > For boot time configuration, agree, there isn't much point in enabling > both options. In addition to boot time, rcu_cpu_stall_suppress can > be temporarily enabled during some operations like sysrq; but this may > not be a use case worth consideration. OK, I will skip this one, for the time being at least. But thank you for your review and patches! Thanx, Paul > >>Fixes: 8c7c4829a81c ("rcu: Awaken grace-period kthread if too long since FQS") > >>Signed-off-by: Neeraj Upadhyay <neeraju@...eaurora.org> > >>--- > >> kernel/rcu/tree.c | 7 +++++-- > >> 1 file changed, 5 insertions(+), 2 deletions(-) > >> > >>diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > >>index 51d4c3a..91b7552 100644 > >>--- a/kernel/rcu/tree.c > >>+++ b/kernel/rcu/tree.c > >>@@ -1562,10 +1562,13 @@ static void check_cpu_stall(struct rcu_state *rsp, struct rcu_data *rdp) > >> unsigned long js; > >> struct rcu_node *rnp; > >> > >>- if ((rcu_cpu_stall_suppress && !rcu_kick_kthreads) || > >>- !rcu_gp_in_progress(rsp)) > >>+ if (!rcu_gp_in_progress(rsp)) > >> return; > >> rcu_stall_kick_kthreads(rsp); > >>+ > >>+ if (rcu_cpu_stall_suppress) > >>+ return; > >>+ > >> j = jiffies; > >> > >> /* > >>-- > >>QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a > >>member of the Code Aurora Forum, hosted by The Linux Foundation > >> > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a > member of the Code Aurora Forum, hosted by The Linux Foundation >
Powered by blists - more mailing lists