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]
Date:	Wed, 13 Aug 2014 16:42:19 +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,
	rafael@...nel.org
Subject: Re: [PATCH v5 tip/core/rcu 15/16] rcu: Make RCU-tasks wait for idle
 tasks

On Wed, Aug 13, 2014 at 07:12:17AM -0700, Paul E. McKenney wrote:
> > That's not an excuse for doing horrible things. And inventing new infra
> > that needs to wake all CPUs is horrible.
> 
> Does your patch even work? 

Haven't even tried compiling it, but making it work shouldn't be too
hard.

> Looks like it should, and yes, the idle loop
> seems quite a bit simpler than it was a few years ago, but we really
> don't need some strange thing that leaves a CPU idle but not visible as
> such to RCU.

There's slightly more to it though; things like the x86 mwait idle wait
functions tend to do far too much; for instance look at:

drivers/idle/intel_idle.c:intel_idle()

We should push the rcu_idle_{enter,exit}() down to around
mwait_idle_with_hints(), so we don't call half the word with RCU
disabled.

> I have already said that I will be happy to rip out the wakeup code
> when it is no longer needed, and I agree that it would be way better if
> not needed.

I'd prefer to dtrt now and not needing to fix it later.

Auditing all idle functions will be somewhat of a pain, but its entirely
doable. Looking at this stuff, it appears we can clean it up massively;
see how the generic cpuidle code already has the broadcast logic in, so
we can remove that from the drivers by setting the right flags.

We can similarly pull out the leave_mm() call by adding a
CPUIDLE_FLAG_TLB_FLUSH. At which point all we'd need to do is mark the
intel_idle (and all other cpuidle_state::enter functions with __notrace.

> But I won't base a patch on hypotheticals.  You have already
> drawn way too much water from -that- well over the past years!  ;-)

not entirely sure what you're referring to there ;-)

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ