| 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
| ||
|
Message-ID: <CAFbHwiSkqpRUv2CW8sqL8XQEkbbvtos2h5UTTX19jeXJNrBOUA@mail.gmail.com> Date: Wed, 27 Jul 2011 14:09:38 +0100 From: Will Newton <will.newton@...il.com> To: Arnd Bergmann <arnd@...db.de> Cc: Linux Kernel list <linux-kernel@...r.kernel.org>, stable@...nel.org Subject: Re: [PATCH] bitops: Use volatile in generic atomic bitops. On Wed, Jul 27, 2011 at 1:55 PM, Arnd Bergmann <arnd@...db.de> wrote: > On Wednesday 27 July 2011, Will Newton wrote: >> The generic atomic bitops currently explicitly cast away the >> volatile from the pointer passed to them. This will allow the >> access to the bitfield to happen outside of the critical section >> thus making the bitops no longer interrupt-safe. Remove this cast >> and add a volatile keyword to make sure all accesses to the >> bitfield happen inside the critical section. >> >> Signed-off-by: Will Newton <will.newton@...tec.com> > > Have you observed this behavior? The interrupt disable/enable should > always come with a barrier that should prevent the bitops from > leaking out, so I don't see how this causes problems in practice. Yes, although my arch does not have these barriers. Now I see from memory-barriers.txt that lock/unlock are required to implement a compiler barrier, sorry for the noise! -- 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