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: Mon, 11 May 2015 10:50:42 -0700 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Peter Zijlstra <peterz@...radead.org> Cc: Douglas Hatch <doug.hatch@...com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...nel.org>, Waiman Long <Waiman.Long@...com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "Norton, Scott J" <scott.norton@...com>, Peter Anvin <hpa@...or.com>, "linux-tip-commits@...r.kernel.org" <linux-tip-commits@...r.kernel.org> Subject: Re: [tip:locking/core] locking/pvqspinlock: Replace xchg() by the more descriptive set_mb() On Mon, May 11, 2015 at 7:54 AM, Peter Zijlstra <peterz@...radead.org> wrote: > > Hmm, so I looked at the set_mb() definitions and I figure we want to do > something like the below, right? I don't think you need to do this for the non-smp cases. The whole thing is about smp memory ordering, so on UP you don't even need the WRITE_ONCE(), much less a barrier. That said, I do wonder if we should make that "it's only an smp barrier" more explicit. We have non-smp barriers for people who do DMA, and while they should probably never use anything like set_mb() anyway (they tend to want *release* semantics, not a full barrier), from a conceptual standpoint the "set_mb()" function really is closer to the "smp_store_release()/smp_load_acquire()" family of macros. So I wonder if we should change the name to match. IOW, if we are really cleaning up smp_mb() and changing most of the lines associated with it (we really have very few users, and there seems to be more lines *defining* smp_mb() than there are lines *using* it in the kernel), maybe we should also just rename it "smp_store_mb()" at the same time. I dunno. Maybe the churn isn't worth it. Linus -- 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