Message ID | 20140606171145.GU13930@laptop.programming.kicks-ass.net (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
On 6/6/2014 1:11 PM, Peter Zijlstra wrote: > The thing is, all these archs are broken beyond this particular problem, > Mikulas Patocka found a number of other spots. > > In any case, sure I can exclude more. Although ideally someone goes do > that __atomic sparse thing to flush out all this. > > --- > Subject: locking, mutex: Disable optimistic spinning on !RMW archs > > For some archs a regular store does not play nice with cmpxchg(), the > optimistic spinning code (and various other places not caught by this) > break this assumption and make things go boom. > > Until something better is found, disable optimistic spinning for these > archs. > > [..] > > +config ARCH_NO_ATOMIC_RMW > + def_bool y > + depends on PARISC || SPARC32 || METAG_ATOMICITY_LOCK1 || (TILE && !TILEGX) || (ARC && !ARC_HAS_LLSC) For tile: Acked-by: Chris Metcalf <cmetcalf@tilera.com> But you should use "TILEPRO" (added in kernel 3.5) instead of "(TILE && !TILEGX)".
On Fri, Jun 6, 2014 at 10:11 AM, Peter Zijlstra <peterz@infradead.org> wrote: > > +config ARCH_NO_ATOMIC_RMW > + def_bool y > + depends on PARISC || SPARC32 || METAG_ATOMICITY_LOCK1 || (TILE && !TILEGX) || (ARC && !ARC_HAS_LLSC) Ugh. We've had these kinds of things before, and they are broken and nasty to maintain. Just make it config ARCH_SUPPORTS_ATOMIC_RMW bool which defaults to no. And then make MUTEX_SPIN_ON_OWNER depend on that. And then we can add "select ARCH_SUPPORTS_ATOMIC_RMW" to the few architectures we (a) care about and (b) know work. So start with x86, arm, powerpc and sparc64, and then the rest can just add their own oneliners if they care. Remember, most people really won't ever care about this, simply because it only matters if you have enough CPU's for the whole spinning thing to make a noticeable difference. So missing some odd architecture _really_ doesn't matter. And we really really *really* shouldn't have these kinds of "random really odd architecture details" in the generic code, not even if it's something as specific as kernel/Kconfig.locks. Linus Linus -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/kernel/Kconfig.locks b/kernel/Kconfig.locks index d2b32ac27a39..b9c132c48bf1 100644 --- a/kernel/Kconfig.locks +++ b/kernel/Kconfig.locks @@ -220,6 +220,10 @@ config INLINE_WRITE_UNLOCK_IRQRESTORE endif +config ARCH_NO_ATOMIC_RMW + def_bool y + depends on PARISC || SPARC32 || METAG_ATOMICITY_LOCK1 || (TILE && !TILEGX) || (ARC && !ARC_HAS_LLSC) + config MUTEX_SPIN_ON_OWNER def_bool y - depends on SMP && !DEBUG_MUTEXES + depends on SMP && !DEBUG_MUTEXES && !ARCH_NO_ATOMIC_RMW