linux-kernel - Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

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]

Message-ID: <20131216224006.GA5919@linux.vnet.ibm.com>
Date:	Mon, 16 Dec 2013 14:40:06 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Jochen Striepe <jochen@...ot.escape.de>
Cc:	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

On Tue, Dec 10, 2013 at 12:22:57PM +0100, Jochen Striepe wrote:
> 	Hi again,
> 
> On Fri, Dec 06, 2013 at 06:54:41AM -0800, Paul E. McKenney wrote:
> > On Fri, Dec 06, 2013 at 02:58:04PM +0100, Jochen Striepe wrote:
> > > On Thu, Dec 05, 2013 at 04:26:14PM -0800, Paul E. McKenney wrote:
> > > > Hmmm...  Does the following patch help?
> > > [...]
> > > > rcu: Kick CPU halfway to RCU CPU stall warning
> > > 
> > > The stall didn't appear at all since my last email, running 3.12.x
> > > kernels since release. But I will test your patch later today. I assume
> > > applying on top of 3.12.3 is correct?
> > 
> > 3.12.3 should take that patch just fine.
> 
> Sorry for the delay. On my copy of 3.12.3, the patch does not apply.
> kernel/rcu/ does not exist, and the patch did not apply cleanly on
> kernel/rcutree.c: record_gp_stall_check_time() is a little different
> from what your patch expects, and I'm not that much into rcu work as
> to understand the implications. :)
> 
> If you want me to go back to 3.12.0 I can do so, but as the issue
> does not reproduce very well I doubt that would help very much.
> Ideas? Is there a version of the patch for -stable, or does the
> patch conflict with the work done there?

And you are quite right, there is a prerequisite commit.  I have attached
both, please apply in numeric order.

The subdirectory causes problems for patches, but git cherry-pick actually
deals with this sort of thing.

Because patch.2 has not yet made it to mainline, it is not yet eligible
for -stable.  I expect it to hit mainline in the 3.14 merge window,
which will likely be coming up in a few weeks.

							Thanx, Paul

View attachment "stall.1" of type "text/plain" (5701 bytes)

View attachment "stall.2" of type "text/plain" (2936 bytes)