linux-kernel - Re: [PATCH] arch: Introduce read

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: <54637B6A.9070204@redhat.com>
Date:	Wed, 12 Nov 2014 07:23:22 -0800
From:	Alexander Duyck <alexander.h.duyck@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Will Deacon <will.deacon@....com>,
	"alexander.duyck@...il.com" <alexander.duyck@...il.com>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Michael Neuling <mikey@...ling.org>,
	Tony Luck <tony.luck@...el.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Michael Ellerman <michael@...erman.id.au>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Russell King <linux@....linux.org.uk>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH] arch: Introduce read_acquire()

On 11/12/2014 02:15 AM, Peter Zijlstra wrote:
> On Tue, Nov 11, 2014 at 01:12:32PM -0800, Alexander Duyck wrote:
>>> Minor nit on naming, but load_acquire would match what we do with barriers,
>>> where you simply drop the smp_ prefix if you want the thing to work on UP
>>> systems too.
>> The problem is this is slightly different, load_acquire in my mind would use
>> a mb() call, I only use a rmb().  That is why I chose read_acquire as the
>> name.
> acquire is not about rmb vs mb, do read up on
> Documentation/memory-barriers.txt. Its a distinctly different semantic.
> Some archs simply lack the means of implementing this semantics and have
> to revert to mb (stronger is always allowed).
>
> Using the read vs load to wreck the acquire semantics is just insane.

Actually I have been reading up on it as I wasn't familiar with C11.  
Most of what I was doing was actually based on the documentation in 
barriers.txt which was referring to memory operations not loads/stores 
when referring to the acquire/release so I assumed the full memory 
barrier was required.  I wasn't aware that smp_load_acquire was only 
supposed to be ordering loads, or that smp_ store_release only applied 
to stores.I will probably go back and re-implement this patch as 
introducing load_acquire and add store_release as well.  I figure it is 
possible that a device could be doing something like reading a linked 
list in memory ("Example combining sync and lwsync" 
http://www.ibm.com/developerworks/systems/articles/powerpc.html#N102B1) 
and then you would need both the store_release and the wmb() to deal 
with system memory vs system memory ordering, and system memory vs MMIO.

Base drivers have been doing this kind of stuff for a while.  The 
problem is we have been doing it using barriers that are heavier than 
they need to be.  For example the reason why I am wanting to shift to 
using something like an acquire operation is because the current barrier 
we have been using, rmb(), is far heavier than we need for system memory 
vs system memory ordering on systems such as PowerPC.  What I am looking 
for with the load_acquire/store_release is to allow for the use of 
lighter weight barriers for updates that only affect system memory.

Thanks,

Alex

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