linux-kernel - Re: linux-next: build warnings after merge of the access

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: <20150326142220.GY21418@twins.programming.kicks-ass.net>
Date:	Thu, 26 Mar 2015 15:22:20 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Will Deacon <will.deacon@....com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Christian Borntraeger <borntraeger@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Davidlohr Bueso <dave@...olabs.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>
Subject: Re: linux-next: build warnings after merge of the access_once tree

On Thu, Mar 26, 2015 at 01:27:50PM +0000, Will Deacon wrote:
> On Thu, Mar 26, 2015 at 10:34:42AM +0000, Peter Zijlstra wrote:
> > On Thu, Mar 26, 2015 at 07:31:12PM +1100, Stephen Rothwell wrote:
> > > In function '__read_once_size',
> > >     inlined from 'lockref_get' at lib/lockref.c:50:2:


> Yeah, I think it's fine because, as you point out, the cmpxchg can only
> succeed if the 64-bit load appeared to be single-copy atomic (amongst other
> things).

So one option to get rid of this warning is to rely on the fact that all
CMPXCHG_LOOP users are at the beginning of !pure function calls, which
already imply a compiler barrier and therefore it must already emit that
load.

And as already argued, split loads aren't an issue because the cmpxchg
will catch those for us.

So we can either just remove the READ_ONCE(), or replace it with a
leading barrier() call just to be on the paranoid side of things.

Any preferences?

Something like so, but with a sensible comment I suppose.

---
 lib/lockref.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/lockref.c b/lib/lockref.c
index 494994bf17c8..b5ca1f65c8a3 100644
--- a/lib/lockref.c
+++ b/lib/lockref.c
@@ -18,7 +18,8 @@
 #define CMPXCHG_LOOP(CODE, SUCCESS) do {					\
 	struct lockref old;							\
 	BUILD_BUG_ON(sizeof(old) != 8);						\
-	old.lock_count = READ_ONCE(lockref->lock_count);			\
+	barrier();								\
+	old.lock_count = lockref->lock_count;					\
 	while (likely(arch_spin_value_unlocked(old.lock.rlock.raw_lock))) {  	\
 		struct lockref new = old, prev = old;				\
 		CODE								\
--
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/