linux-kernel - Re: tty^Wrcu/perf lockdep trace.

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: <20131004170954.GK5790@linux.vnet.ibm.com>
Date:	Fri, 4 Oct 2013 10:09:54 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	gregkh@...uxfoundation.org, peter@...leysoftware.com
Subject: Re: tty^Wrcu/perf lockdep trace.

On Fri, Oct 04, 2013 at 06:50:44PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 04, 2013 at 09:03:52AM -0700, Paul E. McKenney wrote:
> > The problem exists, but NOCB made it much more probable.  With non-NOCB
> > kernels, an irq-disabled call_rcu() invocation does a wake_up() only if
> > there are more than 10,000 callbacks stacked up on the CPU.  With a NOCB
> > kernel, the wake_up() happens on the first callback.
> 
> Oh I see.. so I was hoping this was some NOCB crackbrained damage we
> could still 'fix'.
> 
> And that wakeup is because we moved grace-period advancing into
> kthreads, right?

Yep, in earlier kernels we would instead be doing raise_softirq().
Which would instead wake up ksoftirqd, if I am reading the code
correctly -- spin_lock_irq() does not affect preempt_count.

> > I am not too happy about the complexity of deferring, but maybe it is
> > the right approach, at least assuming perf isn't going to whack me
> > with a timer lock.  ;-)
> 
> I'm not too thrilled about trying to move the call_rcu() usage either.

Understood!

> > Any other approaches that I am missing?
> 
> Probably; so the regular no-NOCB would be easy to work around by
> providing me a call_rcu variant that never does the wakeup.

Well, if we can safely, sanely, and reliably defer the wakeup, there is
no reason not to make plain old call_rcu() do what you need.  If there
is no such way to defer the wakeup, then I don't see how to make that
variant.

> NOCB might be a little more difficult; depending on the reason why it
> needs to do this wakeup on every single invocation; that seems
> particularly expensive.

Not on every single invocation, just on those invocations where the list
is initially empty.  So the first call_rcu() on a CPU whose rcuo kthread
is sleeping will do a wakeup, but subsequent call_rcu()s will just queue,
at least until rcuo goes to sleep again.  Which takes awhile, since it
has to wait for a grace period before invoking that first RCU callback.

> Man, RCU was so much easier when all it was was a strict per-cpu state
> with timer-interrupt driven state machine; non of all this nonsense.

Tell me about it!  This bit about avoiding scheduling-clock interrupts
for all sorts of reasons has most definitely added to my collection of
gray hairs.  ;-)

							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/