linux-kernel - Re: memory barrier question

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: <20100920182504.GD2408@linux.vnet.ibm.com>
Date:	Mon, 20 Sep 2010 11:25:04 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	James.Bottomley@...senPartnership.com, benh@...nel.crashing.org,
	dhowells@...hat.com, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org
Subject: Re: memory barrier question

On Mon, Sep 20, 2010 at 06:01:58PM +0200, Miklos Szeredi wrote:
> On Sun, 19 Sep 2010, Paul E. McKenney wrote:
> > > > Again, please put at least an ACCESS_ONCE() in.  Trivial to do now,
> > > > possibly saving much pain and headache later on.
> > > 
> > > OK, lost you here.  ACCESS_ONCE() is only needed in certain situations
> > > (like list traversal) because some compilers can reload cached values
> > > across an explicit barrier (which isn't here).
> > 
> > ACCESS_ONCE() also tells the compiler not to try to guess.
> 
> If the code is written like this:
> 
> 	if (ACCESS_ONCE(dentry->d_inode)) {
> 		blah = dentry->d_inode->i_some_field
> 		...
> 	}
> 
> does the compiler guarantee anything or does it need a full compiler
> barrier to prevent reordering?

>From what I understand, this could do strange things.  The compiler
is forced to access dentry->d_inode for the "if" check, but would be
free to use some previously fetched value for the assignment to "blah".
Unless of course this code was under a lock that prevented any
change to dentry->d_inode.

If the code is to execute in a lockless manner, I would instead suggest
something like the following:

	p = ACCESS_ONCE(dentry->d_inode);
	if (p) {
		blah = p->i_some_field
		...
	}

This would force the compiler to actually fetch dentry->d_inode
and only then dereference it.

This would -not- constrain the CPU in any way, but the only CPU that
I know of that misbehaves in this case is DEC Alpha.

So my version of the above code would do what you expect on most CPUs,
but really could fail on DEC Alpha.  If you don't believe me, please feel
free to take a look at http://www.openvms.compaq.com/wizard/wiz_2637.html.

But do we really care about Alpha anymore?  (I can see it now... The
Alpha portion of the kernel tree moves to staging...)

> Because that pattern is, again, pretty much all over the place.  Yeah
> it can be rewritten but that's not always feasable since it's
> difficult to audit, would possibly need extra function arguments,
> etc...

Again, the pattern is OK if you are preventing the pointer from changing.

							Thanx, Paul
--
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/