linux-kernel - Re: [PATCH RFC tip/core/rcu 1/9] rcu: Add call_rcu

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: <20140729192504.GO3935@laptop>
Date:	Tue, 29 Jul 2014 21:25:04 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...nel.org,
	laijs@...fujitsu.com, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
	josh@...htriplett.org, tglx@...utronix.de, rostedt@...dmis.org,
	dhowells@...hat.com, edumazet@...gle.com, dvhart@...ux.intel.com,
	fweisbec@...il.com, oleg@...hat.com, bobby.prani@...il.com
Subject: Re: [PATCH RFC tip/core/rcu 1/9] rcu: Add call_rcu_tasks()

On Tue, Jul 29, 2014 at 11:19:49AM -0700, Paul E. McKenney wrote:
> > I feel we're doing far too much async stuff already and it keeps getting
> > worse and worse. Ideally we'd be able to account every cycle of kernel
> > 'overhead' to a specific user action.
> 
> Hmmm...
> 
> In theory, we could transfer the overhead of the kthread for a given grace
> period to the task invoking the corresponding synchronize_rcu_tasks().
> In practice, the overhead might need to be parceled out among several
> tasks that concurrently invoked synchronize_rcu_tasks().  Or I suppose
> that the overhead could be assigned to the first such task that woke
> up, on the theory that things would even out over time.
> 
> So exactly how annoyed are you about the lack of accounting?  ;-)

Its a general annoyance that people don't seem to consider this at all.

And RCU isn't the largest offender by a long shot.

> > Another reason is that I fundamentally dislike polling stuff.. but yes,
> > I'm not really seeing how to do this differently, partly because I'm not
> > entirely sure why we need this to begin with. I'm not sure what problem
> > we're solving.
> 
> As I recall it...
> 
> Steven is working on some sort of tracing infrastructure that involves
> dynamically allocated trampolines being inserted into some/all functions.
> The trampoline code can be preempted, but never does voluntary context
> switches, and presumably never calls anything that does voluntary
> context switches.
> 
> Easy to insert a trampoline, but the trick is removing them.
> 
> The thought is to restore the instructions at the begining of the
> function in question, wait for an RCU-tasks grace period, then dispose
> of the trampoline.
> 
> Of course, you could imagine disabling preemption or otherwise entering
> an RCU read-side critical section before transferring to the trampoline,
> but this was apparently a no-go due to the overhead for small functions.

So why not use the freezer to get the kernel into a known good state and
then remove them trampolines? That would mean a more noticeable
disruption of service, but it might be ok for something like disabling a
tracer or so. Dunno.

Kernel threads are the problem here, lemme ponder this for a bit.
--
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/