linux-kernel - Re: [rfc] SLOB memory ordering issue

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: <alpine.LFD.2.00.0810151116430.3288@nehalem.linux-foundation.org>
Date:	Wed, 15 Oct 2008 11:26:37 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Nick Piggin <nickpiggin@...oo.com.au>
cc:	Matt Mackall <mpm@...enic.com>, Hugh Dickins <hugh@...itas.com>,
	Pekka Enberg <penberg@...helsinki.fi>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [rfc] SLOB memory ordering issue

On Thu, 16 Oct 2008, Nick Piggin wrote:
> 
> Who was it that said memory ordering was self-evident?

Nobody has _ever_ said that memory ordering is self-evident. Quite the 
reverse.

What we've said is that it's not a ctor issue. This has nothing 
what-so-ever to do with ctors, and everything to do with the fact that 
lockless is hard.

And the general rule is: to find a page (or any other data structures) on 
another CPU, you need to insert it into the right data structures. And 
that insertion event needs to either be locked, or it needs to be ordered.

But notice that it's the _insertion_ event. Not the ctor. Not the 
allocator. It's the person _doing_ the allocation that needs to order 
things.

See?

And no, I didn't look at your exact case. But for pages in page tables, 
we'd need to have the right smp_wmb() at the "set_pte[_at]()" stage, 
either inside that macro or in the caller.

We used to only care about the page _contents_ (because the only unlocked 
access was the one that was done by hardware), but now that we do unlocked 
lookups in software too, we need to make sure the "struct page" itself is 
also valid.

For non-page-table lookups (LRU, radix trees, etc etc), the rules are 
different. Again, it's not an _allocator_ (or ctor) issue, it's about the 
point where you insert the thing. If you insert the page using a lock, you 
need not worry about memory ordering at all. And if you insert it using 
RCU, you do.

This is *all* we have argued about. The argument is simple: this has 
NOTHING to do with the allocator, and has NOTHING to do with constructors.

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