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: Sun, 2 Jun 2019 13:54:12 -0700 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Herbert Xu <herbert@...dor.apana.org.au> Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, Frederic Weisbecker <fweisbec@...il.com>, Boqun Feng <boqun.feng@...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> Subject: Re: rcu_read_lock lost its compiler barrier On Sat, Jun 1, 2019 at 10:56 PM Herbert Xu <herbert@...dor.apana.org.au> wrote: > > You can't then go and decide to remove the compiler barrier! To do > that you'd need to audit every single use of rcu_read_lock in the > kernel to ensure that they're not depending on the compiler barrier. What's the possible case where it would matter when there is no preemption? Linus
Powered by blists - more mailing lists