linux-kernel - Re: [PATCH] kernel: fix data race in put

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:	Fri, 18 Sep 2015 13:31:27 +0100
From:	James Hogan <james.hogan@...tec.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Oleg Nesterov <oleg@...hat.com>,
	Dmitry Vyukov <dvyukov@...gle.com>, <ebiederm@...ssion.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>, <mhocko@...e.cz>,
	LKML <linux-kernel@...r.kernel.org>, <ktsan@...glegroups.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Andrey Konovalov <andreyknvl@...gle.com>,
	"Alexander Potapenko" <glider@...gle.com>,
	Hans Boehm <hboehm@...gle.com>
Subject: Re: [PATCH] kernel: fix data race in put_pid

Hi Peter,

On Fri, Sep 18, 2015 at 11:27:32AM +0200, Peter Zijlstra wrote:
> On Fri, Sep 18, 2015 at 10:57:32AM +0200, Peter Zijlstra wrote:
> > diff --git a/arch/metag/include/asm/atomic_lnkget.h b/arch/metag/include/asm/atomic_lnkget.h
> > index 21c4c268b86c..1bd21c933435 100644
> > --- a/arch/metag/include/asm/atomic_lnkget.h
> > +++ b/arch/metag/include/asm/atomic_lnkget.h
> > @@ -3,7 +3,8 @@
> >  
> >  #define ATOMIC_INIT(i)	{ (i) }
> >  
> > -#define atomic_set(v, i)		((v)->counter = (i))
> > +/* XXX: should be LNKSETD ? */
> > +#define atomic_set(v, i)		WRITE_ONCE((v)->counter, (i))
> >  
> >  #include <linux/compiler.h>
> >  
> 
> James?

It should be fine without a LNKSET. The only reason LNKGET is required
for atomic_read() is that on certain cores the LNKGET/LNKSET
instructions went around the cache, but those cores also have write
through caches, so it shouldn't result in incoherence.

I've just double checked, and the pipeline seems to handle the linked
read after write correctly, so e.g. after:

0220002c    MOV       D0FrT,#0x5
b6208042    SETD      [D1Ar3],D0FrT
ad1080cc    LNKGETD   D0Ar4,[D1Ar3]

D0Ar4 is correct (0x5).

Cheers
James

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)