linux-kernel - Re: [PATCH RFC] percpu: add data dependency barrier in percpu accessors and operations

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140617185605.GL31819@htj.dyndns.org>
Date:	Tue, 17 Jun 2014 14:56:05 -0400
From:	Tejun Heo <tj@...nel.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	Christoph Lameter <cl@...ux-foundation.org>,
	David Howells <dhowells@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH RFC] percpu: add data dependency barrier in percpu
 accessors and operations

Hello, Paul.

On Tue, Jun 17, 2014 at 09:57:02AM -0700, Paul E. McKenney wrote:
> I am not sure that this is actually better than having the allocating
> CPU do the initialization, though, even given a large number of CPUs.
> Or maybe even especially given a large number of CPUs.  The bit about
> asking all the other CPUs to do their allocations and initializations
> and then waiting for them to respond might not be pretty.

If it ever happens, it'd probably be the allocator trying to keep
certain amount ready as allocation buffer with buffer refill
synchronization happening lazily in large chunks.  We don't need
anything like that at this point.  I was trying to point out that the
semantics isn't immediately clear.

> > * Add data dependency barrier to percpu accessors and write barrier to
> >   the allocator with the comment that this will be replaced with
> >   proper assignment macros and mark this change w/ -stable.
> > 
> > * Later, introduce percpu pointer assignment macros and convert all
> >   users and remove the wmb added above.
> 
> This longer-term approach seems like a good one to me.

Alright, going that way then.  This will bring percpu usages very
close to RCU, which I like.

> I much prefer the model where the thing that -published- the pointer is
> responsible for memory ordering.  After all, if a task allocates some
> zeroed memory, uses it locally, then frees it, there is no ordering
> to worry about in the first place.  The memory allocator doing the
> initialization cannot tell how the memory is to be used, after all.

Yeah, "publish" is a nice verb to put on it.  No objection.

Thanks.

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