On Tue, 2018-03-27 at 15:13 +0200, Andrea Parri wrote: > > > > So unless it's very performance sensitive, I'd rather have things like > > spin_is_locked be conservative by default and provide simpler ordering > > semantics. > > Well, it might not be "very performance sensitive" but allow me to say > that "40+ SYNCs in stuff like BUG_ON or such" is sadness to my eyes ;),
In the fast path or the trap case ? Because the latter doesn't matter at all... > especially when considered that our "high level API" provides means to > avoid this situation (e.g., smp_mb__after_spinlock(); BTW, if you look > at architectures for which this macro is "non-trivial", you can get an > idea of the architectures which "wouldn't work"; of course, x86 is not > among these). Yes, we do appear to have different views on what is to > be considered the "simpler ordering semantics". I'm willing to change > mine _as soon as_ this gets documented: would you be willing to send a > patch (on the lines of my [1]) to describe/document such semantics? Not really :-) Just expressing an opinion. I don't fully object to your approach, just saying it's open for debate. At this point, I have too many other things to chase to follow up too much on this. Cheers, Ben.
