* Andrew Morton <[email protected]> wrote:
> And yes, the mutex code will (with debug enabled) unconditionally
> enable interrupts. ppc64 tends to oops when this happens, in the
> timer handler (so it'll be intermittent...)
hm, i sent a patch to fix that, long time ago.
> But looking at
> work-around-ppc64-bootup-bug-by-making-mutex-debugging-save-restore-irqs.patch
> I realise I don't understand it. We only go into the irq-enabling
> code in the case of contention, and there cannot be contention in this
> case?
in the debug case we go into the 'slowpath' all the time - so that we
can do the debug checks under the mutex lock.
if we get real contention then we have a might_sleep() check that will
catch that.
i'd suggest to push
work-around-ppc64-bootup-bug-by-making-mutex-debugging-save-restore-irqs.patch
upstream - i thought we agreed that while it's a bit hacky and slows the
mutex code down a bit, it's not practical right now to forbid
uncontended mutex_lock() in early init code?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
