linux-kernel - Re: [tip:core/rcu] rcu: Break call_rcu() deadlock involving scheduler and perf

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]

Message-ID: <20131216161031.GD4200@linux.vnet.ibm.com>
Date:	Mon, 16 Dec 2013 08:10:31 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...nel.org, hpa@...or.com,
	tglx@...utronix.de, davej@...hat.com,
	linux-tip-commits@...r.kernel.org, laijs@...fujitsu.com
Subject: Re: [tip:core/rcu] rcu: Break call_rcu() deadlock involving
 scheduler and perf

On Mon, Dec 16, 2013 at 04:45:39PM +0100, Peter Zijlstra wrote:
> On Mon, Dec 16, 2013 at 07:32:48AM -0800, Paul E. McKenney wrote:
> > On Mon, Dec 16, 2013 at 04:26:36PM +0100, Peter Zijlstra wrote:
> > > On Mon, Dec 16, 2013 at 07:19:22AM -0800, tip-bot for Paul E. McKenney wrote:
> > > > The underlying problem is that perf is invoking call_rcu() with the
> > > > scheduler locks held, but in NOCB mode, call_rcu() will with high
> > > > probability invoke the scheduler -- which just might want to use its
> > > > locks.  The reason that call_rcu() needs to invoke the scheduler is
> > > > to wake up the corresponding rcuo callback-offload kthread, which
> > > > does the job of starting up a grace period and invoking the callbacks
> > > > afterwards.
> > > > 
> > > > One solution (championed on a related problem by Lai Jiangshan) is to
> > > > simply defer the wakeup to some point where scheduler locks are no longer
> > > > held.  Since we don't want to unnecessarily incur the cost of such
> > > > deferral, the task before us is threefold:
> > > > 
> > > > 1.	Determine when it is likely that a relevant scheduler lock is held.
> > > > 
> > > > 2.	Defer the wakeup in such cases.
> > > > 
> > > > 3.	Ensure that all deferred wakeups eventually happen, preferably
> > > > 	sooner rather than later.
> > > > 
> > > > We use irqs_disabled_flags() as a proxy for relevant scheduler locks
> > > > being held.  This works because the relevant locks are always acquired
> > > > with interrupts disabled.  We may defer more often than needed, but that
> > > > is at least safe.
> > > 
> > > This would also allow us to do away with things like the below patch,
> > > right?
> > 
> > It takes care of one problem, but there are others, including
> > rcu_read_unlock() inovking the scheduler to deboost itself.  So for the
> > moment, we still need the below patch.
> 
> Oh right, see I knew I was forgetting something... :-)

I am hoping to make your patch unnecessary, but it ain't trivial.  ;-)

We will get there!  Especially if I can find Lai Jiangshan's old patch
that reworked deboosting.  :-/

							Thanx, Paul

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