linux-kernel - Re: per-cpu operation madness vs validation

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, 27 Jul 2011 09:20:01 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Tejun Heo <tj@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Paul E. McKenney" <paulmck@...ibm.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: per-cpu operation madness vs validation

On Wed, 27 Jul 2011, Peter Zijlstra wrote:

> > Possibly we could reduce all this percpu madness back to one form
> > (__this_cpu_*) and require that when used a lock of the percpu_lock_t is
> > taken.
>
> get_cpu_var()/put_cpu_var() were supposed to provide such delineation as
> well, but you've been actively destroying things like that with the
> recent per-cpu work.

The per cpu work is *not* focused on sections that access per cpu data, so
how could it destroy that? Nothing is changed there so far. The this_cpu
ops are introducing per cpu atomic operations that are safe and cheap
regardless of the execution context. The primary initial motivation was
incrementing per cpu counters without having to disabling interrupts
and/or preemption and it grew from there.

The atomic per cpu operations (like the this_cpu_cmpxchg) allow the
construction of cheap sections that would satisfy your goals too (with
some work and the use of transaction ids instead of locking). See the slub
fastpath f.e.

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