linux-kernel - Re: [PATCH 1/2] rcu: Assign higher priority to RCU threads if its rcutorture

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 19 Jun 2018 09:00:24 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Joel Fernandes <joel@...lfernandes.org>
Cc:     linux-kernel@...r.kernel.org, kernel-team@...roid.com,
        Josh Triplett <josh@...htriplett.org>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Byungchul Park <byungchul.park@....com>
Subject: Re: [PATCH 1/2] rcu: Assign higher priority to RCU threads if its
 rcutorture

On Mon, Jun 18, 2018 at 11:34:21PM -0700, Joel Fernandes wrote:
> On Mon, Jun 18, 2018 at 11:22:14PM -0700, Joel Fernandes wrote:
> > From: "Joel Fernandes (Google)" <joel@...lfernandes.org>
> > 
> > rcutorture boost tests fail even with CONFIG_RCU_BOOST set because
> > rcutorture's threads are equal priority to the default RCU kthreads (RT
> > class with priority of 1).
> 
> Sorry for the weird subject line, I meant "rcu: Assign higher prio if
> rcutorture is built into kernel". I have included the patch with the subject
> line fixed up below (if you prefer to take that instead).
> 
> Also one question, incase rcutorture is a module, we can't raise the priority
> of the kthreads because it would be too late to do at module load time. In
> this case, do you have any ideas on what we can do? I was thinking we can
> access the kernel command line from within rcutorture module and check if
> 'rcutree.kthread_prio' was passed. And if it is and isn't sufficiently high,
> then we avoid testing boost feature at all (and print a nice message telling
> the user about the issue).

I do like the idea of checking and printing the message in this case.

Another alternative would be to allow rcutree.kthread_prio to be changed
at runtime.  But one caution: rcutree.kthread_prio applies to a number
of kthreads, not just the boost kthreads, so this approach might have
some unwelcome side-effects.

> OTOH, we can just let rcutorture module loaders fail the test if you feel
> very few automation tests do the module loading way of rcutorture and so a
> boost test failure there is tolerable. For me, I will likely be running
> rcutorture only as a built-in so I am Ok with not special casing it within
> rcutorture.

I don't know of anyone using the module-loading approach.  Probably
someone somewhere does it from time to time, though.

							Thanx, Paul

> thanks!
> 
>  - Joel
> 
> -----8<---------
> 
> >From 8cb7c2ac98e510abac35fdf2419a3212a587095a Mon Sep 17 00:00:00 2001
> From: "Joel Fernandes (Google)" <joel@...lfernandes.org>
> Date: Mon, 18 Jun 2018 15:13:10 -0700
> Subject: [PATCH 1/2] rcu: Assign higher prio if rcutorture is built into kernel
> 
> rcutorture boost tests fail even with CONFIG_RCU_BOOST set because
> rcutorture's threads are equal priority to the default RCU kthreads (RT
> class with priority of 1).
> 
> This patch checks if RCU torture is built into the kernel and if so,
> assigns a higher priority to the RCU threads. With this the rcutorture
> boost tests pass.
> 
> Signed-off-by: Joel Fernandes (Google) <joel@...lfernandes.org>
> ---
>  kernel/rcu/tree.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index deb2508be923..a141d6314622 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -171,7 +171,7 @@ static void rcu_report_exp_rdp(struct rcu_state *rsp,
>  static void sync_sched_exp_online_cleanup(int cpu);
> 
>  /* rcuc/rcub kthread realtime priority */
> -static int kthread_prio = IS_ENABLED(CONFIG_RCU_BOOST) ? 1 : 0;
> +static int kthread_prio;
>  module_param(kthread_prio, int, 0644);
> 
>  /* Delay in jiffies for grace-period initialization delays, debug only. */
> @@ -3884,12 +3884,16 @@ static int __init rcu_spawn_gp_kthread(void)
>  	struct task_struct *t;
> 
>  	/* Force priority into range. */
> -	if (IS_ENABLED(CONFIG_RCU_BOOST) && kthread_prio < 1)
> +	if (IS_ENABLED(CONFIG_RCU_BOOST) && kthread_prio < 2
> +	    && IS_BUILTIN(CONFIG_RCU_TORTURE_TEST))
> +		kthread_prio = 2;
> +	else if (IS_ENABLED(CONFIG_RCU_BOOST) && kthread_prio < 1)
>  		kthread_prio = 1;
>  	else if (kthread_prio < 0)
>  		kthread_prio = 0;
>  	else if (kthread_prio > 99)
>  		kthread_prio = 99;
> +
>  	if (kthread_prio != kthread_prio_in)
>  		pr_alert("rcu_spawn_gp_kthread(): Limited prio to %d from %d\n",
>  			 kthread_prio, kthread_prio_in);
> -- 
> 2.18.0.rc1.244.gcf134e6275-goog
>