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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <E1OxioY-0006nd-M9@pomaz-ex.szeredi.hu>
Date:	Mon, 20 Sep 2010 18:01:58 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	paulmck@...ux.vnet.ibm.com
CC:	James.Bottomley@...senPartnership.com, miklos@...redi.hu,
	benh@...nel.crashing.org, dhowells@...hat.com,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: memory barrier question

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?

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

Thanks,
Miklos
--
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/