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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 21 May 2016 10:14:35 -0700 From: Davidlohr Bueso <dave@...olabs.net> To: Peter Zijlstra <peterz@...radead.org> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Boqun Feng <boqun.feng@...il.com>, Manfred Spraul <manfred@...orfullife.com>, Waiman Long <Waiman.Long@....com>, Ingo Molnar <mingo@...nel.org>, ggherdovich@...e.com, Mel Gorman <mgorman@...hsingularity.net>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Paul McKenney <paulmck@...ux.vnet.ibm.com>, Will Deacon <will.deacon@....com> Subject: Re: sem_lock() vs qspinlocks On Sat, 21 May 2016, Peter Zijlstra wrote: >On Fri, May 20, 2016 at 05:48:39PM -0700, Davidlohr Bueso wrote: >> On Fri, 20 May 2016, Linus Torvalds wrote: >> >> >> >Oh, I definitely agree on the stable part, and yes, the "splt things >> >up" model should come later if people agree that it's a good thing. >> >> The backporting part is quite nice, yes, but ultimately I think I prefer >> Linus' suggestion making things explicit, as opposed to consulting the spinlock >> implying barriers. I also hate to have an smp_mb() (particularly for spin_is_locked) >> given that we are not optimizing for the common case (regular mutual excl). > >I'm confused; we _are_ optimizing for the common case. spin_is_locked() >is very unlikely to be used. And arguably should be used less in favour >of lockdep_assert_held(). Indeed we are. But by 'common case' I was really thinking about spin_is_locked() vs spin_wait_unlock(). The former being the more common of the two, and the one which mostly will _not_ be used for lock correctness purposes, hence it doesn't need that new smp_mb. Hence allowing users to explicitly set the ordering needs (ie spin_lock_synchronize()) seems like the better long term alternative. otoh, with your approach all such bugs are automatically fixed :) Thanks, Davidlohr
Powered by blists - more mailing lists