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
| ||
|
Date: Thu, 6 Jun 2019 03:58:17 -0700 From: "Paul E. McKenney" <paulmck@...ux.ibm.com> To: Herbert Xu <herbert@...dor.apana.org.au> Cc: Alan Stern <stern@...land.harvard.edu>, Boqun Feng <boqun.feng@...il.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Frederic Weisbecker <fweisbec@...il.com>, Fengguang Wu <fengguang.wu@...el.com>, LKP <lkp@...org>, LKML <linux-kernel@...r.kernel.org>, Netdev <netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>, Andrea Parri <andrea.parri@...rulasolutions.com>, Luc Maranget <luc.maranget@...ia.fr>, Jade Alglave <j.alglave@....ac.uk> Subject: Re: rcu_read_lock lost its compiler barrier On Thu, Jun 06, 2019 at 05:28:55PM +0800, Herbert Xu wrote: > On Thu, Jun 06, 2019 at 02:06:19AM -0700, Paul E. McKenney wrote: > > > > Or is your point instead that given the initial value of "a" being > > zero and the value stored to "a" being one, there is no way that > > any possible load and store tearing (your slicing and dicing) could > > possibly mess up the test of the value loaded from "a"? > > Exactly. If you can dream up of a scenario where the compiler can > get this wrong I'm all ears. I believe that this is safe in practice, as long as you exercise constant vigilance. (OK, OK, I might be overdramatizing...) I cannot immediately think of a way that the compiler could get this wrong even in theory, but similar code sequences can be messed up. The reason for this is that in theory, the compiler could use the stored-to location as temporary storage, like this: a = whatever; // Compiler uses "a" as a temporary do_something(); whatever = a; a = 1; // Intended store The compiler is allowed to do this (again, in theory and according to a strict interpretation of the standard) because you haven't told it that anything else is paying attention to variable "a". As a result, the compiler is within its rights to use "a" as temporary storage immediately prior to any plain C-language store to "a". In practice, I don't know of any compilers that actually do this, nor have I heard anyone suggesting that they might soon actually do this. And even if they could, your example would still work because your example doesn't care about anything other than zero and non-zero, so wouldn't get confused by the compiler storing a temporary value of 42 or whatever. > > > But I do concede that in the general RCU case you must have the > > > READ_ONCE/WRITE_ONCE calls for rcu_dereference/rcu_assign_pointer. > > > > OK, good that we are in agreement on this part, at least! ;-) > > Well only because we're allowing crazy compilers that can turn > a simple word-aligned word assignment (a = b) into two stores. In my experience, the insanity of compilers increases with time, but yes. Thanx, Paul
Powered by blists - more mailing lists