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: Tue, 25 Nov 2014 09:50:36 -0800 From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Christian Borntraeger <borntraeger@...ibm.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>, Paolo Bonzini <pbonzini@...hat.com>, Ingo Molnar <mingo@...nel.org>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>, Alexei Starovoitov <alexei.starovoitov@...il.com>, David Howells <dhowells@...hat.com>, Russell King <linux@....linux.org.uk> Subject: Re: [PATCHv2 02/10] kernel: Provide READ_ONCE and ASSIGN_ONCE On Tue, Nov 25, 2014 at 09:28:33AM -0800, Linus Torvalds wrote: > On Tue, Nov 25, 2014 at 7:59 AM, Paul E. McKenney > <paulmck@...ux.vnet.ibm.com> wrote: > > > > We really need something like this to catch invalid sizes: > > > > default: invoke_nonexistent_function(); > > Actually, I wonder if we should make the default: case actually just > do something like > > barrier(); > memcpy(res, p, size); > barrier(); > > which in no way guarantees that it's an _atomic_ access, but it does > guarantee the semantics that you get one particular value and it won't > get reloaded later.. > > That would solve the crazy sparc pte issue too. I would be really worried about confusion due to load/store tearing, where a READ_ONCE() reads part of its value from one ASSIGN_ONCE() and the other part from some other ASSIGN_ONCE(). Don't get me wrong, there are cases where the load/store tearing is harmless, it is just that in my experience that these cases are anything but the common case. That said, I do not claim to be familiar with more than a microscopic fraction of the Linux kernel. Of course, one way to resolve this would be to have one variant that did the memcpy() and another that threw a build error, maybe READ_ONCE_FORCE() and ASSIGN_ONCE_FORC() or some such. I would -really- like to be informed if I do READ_ONCE() of a long long on a 32-bit system. ;-) /me goes off to see if there are any ACCESS_ONCE() of long longs in RCU... 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/
Powered by blists - more mailing lists