linux-kernel - Re: [PATCH RFC] rcu: Make __rcu_read

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: <1332787630.16159.182.camel@twins>
Date:	Mon, 26 Mar 2012 20:47:10 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	paulmck@...ux.vnet.ibm.com
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...icios.com, josh@...htriplett.org,
	niv@...ibm.com, tglx@...utronix.de, rostedt@...dmis.org,
	Valdis.Kletnieks@...edu, dhowells@...hat.com,
	eric.dumazet@...il.com, darren@...art.com, fweisbec@...il.com,
	patches@...aro.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH RFC] rcu: Make __rcu_read_lock() inlinable

On Mon, 2012-03-26 at 11:32 -0700, Paul E. McKenney wrote:
> 
> I could inline them into sched.h, if you are agreeable.

Sure, or put it in kernel/sched/core.c.

> I am a bit concerned about putting them both together because I am betting
> that at least some of the architectures having tracing in switch_to(),
> which I currently do not handle well. 

I would hope not.. there's a generic trace_sched_switch() and
switch_to() is supposed to be black magic. I'd be fine breaking that as
long as we can detect it.

>  At the moment, the ways I can
> think of to handle it well require saving before the switch and restoring
> afterwards.  Otherwise, I can end up with the ->rcu_read_unlock_special
> flags getting associated with the wrong RCU read-side critical section,
> as happened last year.
> 
> Preemption is disabled at this point, correct?

Yeah, and soon we'll have interrupts disabled as well (on all archs,
currently only ARM has interrupts enabled at this point).

> Hmmm...  One way that I could reduce the overhead that preemptible RCU
> imposes on the scheduler would be to move the task_struct queuing from
> its current point upon entry to the scheduler to just before switch_to().
> (The _bh and _sched quiescent states still need to remain at scheduler
> entry.)  That would mean that RCU would not queue tasks that entered
> the scheduler, but did not actually do a context switch.

That would make sense anyhow, right? No point in queueing a task if you
didn't actually switch away from it.

> Would that be helpful?

For now that's preemptible rcu only, and as such a somewhat niche
feature (iirc its not enabled in the big distros) so I don't think it
matters too much. But yeah, would be nice.
--
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/