linux-kernel - Re: rcu_sched stall detected, but no state dump

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] [day] [month] [year] [list]

Date:	Mon, 22 Dec 2014 11:40:11 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Miroslav Benes <mbenes@...e.cz>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: rcu_sched stall detected, but no state dump

On Mon, Dec 22, 2014 at 01:42:14PM +0100, Miroslav Benes wrote:
> On Fri, 19 Dec 2014, Paul E. McKenney wrote:
> > On Fri, Dec 19, 2014 at 12:09:48PM +0100, Miroslav Benes wrote:

[ . . . ]

> > But what do you do if your test module happens to start spinning when
> > there is no callback?
> > 
> > One approach is to do a call_rcu() just after starting your loop.
> > Alternatively, do several just before starting your loop.
> 
> Yes, that would be the way if I understand it correctly. Fortunately there 
> is always some pending RCU callback during my test. I wonder where it 
> comes from (probably module handling. I'll try to find out just to be 
> sure.). 
> 
> So, is the following patch correct? I tested it and it seems ok. And sorry 
> for the delay, I took the weekend off. Thank you for your patience.

Good!  I forward ported it to -rcu, merged the two "if" statements,
queued it, and have started testing.  Thank you!!!

							Thanx, Paul

> Miroslav
> 
> -- >8 --
> >From 0dccc8e322e1a38016422be8f4af110eb7a405fc Mon Sep 17 00:00:00 2001
> From: Miroslav Benes <mbenes@...e.cz>
> Date: Mon, 22 Dec 2014 13:24:44 +0100
> Subject: [PATCH] rcu: Fix RCU CPU stall detection in tiny implementation
> 
> The tiny RCU CPU stall detection depends on *rcp->curtail not being
> NULL. It is however a tail pointer and thus NULL by definition. Instead we
> should check rcp->rcucblist for the presence of pending callbacks which need to
> be processed. With this fix INFO about the stall is printed and jiffies_stall
> (jiffies at next stall) correctly updated.
> 
> Note that the check for pending callback is necessary to avoid spurious warnings
> if there are no pendings callbacks.
> 
> Signed-off-by: Miroslav Benes <mbenes@...e.cz>
> ---
>  kernel/rcu/tiny_plugin.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/rcu/tiny_plugin.h b/kernel/rcu/tiny_plugin.h
> index 858c565..868e132 100644
> --- a/kernel/rcu/tiny_plugin.h
> +++ b/kernel/rcu/tiny_plugin.h
> @@ -145,13 +145,13 @@ static void check_cpu_stall(struct rcu_ctrlblk *rcp)
>  	rcp->ticks_this_gp++;
>  	j = jiffies;
>  	js = ACCESS_ONCE(rcp->jiffies_stall);
> -	if (*rcp->curtail && ULONG_CMP_GE(j, js)) {
> +	if (rcp->rcucblist && ULONG_CMP_GE(j, js)) {
>  		pr_err("INFO: %s stall on CPU (%lu ticks this GP) idle=%llx (t=%lu jiffies q=%ld)\n",
>  		       rcp->name, rcp->ticks_this_gp, rcu_dynticks_nesting,
>  		       jiffies - rcp->gp_start, rcp->qlen);
>  		dump_stack();
>  	}
> -	if (*rcp->curtail && ULONG_CMP_GE(j, js))
> +	if (rcp->rcucblist && ULONG_CMP_GE(j, js))
>  		ACCESS_ONCE(rcp->jiffies_stall) = jiffies +
>  			3 * rcu_jiffies_till_stall_check() + 3;
>  	else if (ULONG_CMP_GE(j, js))
> -- 
> 2.1.2
> 

--
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/