Messages in this thread | | | Date | Mon, 7 Jun 1999 21:48:45 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: [patch] fix for SMP stuck on IPI-TLB-flush [Re: 2.2.9-ac2 locks solid] |
| |
On Mon, 7 Jun 1999, Ingo Molnar wrote:
>On Mon, 7 Jun 1999, Andrea Arcangeli wrote: > >> With this patch applyed a piece of code with irq disabled can also call >> lock_kernel() without risk to deadlock [...] > >this again is only hiding the real bug. All places that aquire the kernel >lock with IRQs disabled are likely to be buggy.
Since it's more robust it doesn't deadlock were the previous code was deadlocking badly. I sure agree that to stay compatible with other ports we must still avoid grabbing the kernel lock with irq disabled, but the Intel port would allow you to do that now. Do you think that being more flexible is a bad thing? The only thing you have to do in the other CPU is to flush the tlb, and you can do that in a NMI or in kernel context without any difference. BTW, I think we could avoid to flush the whole tlb by passing a message to the other CPU via a static per-CPU variable that will contain the address to flush. Looks safe to me. Am I missing something about this?
BTW, the bug was very well hided even now, if you really want to show the bug just add some debugging code to lock_kernel() to do a:
unsigned long flags, flags2; __save_flags(flags); __cli(); __save_flags(flags2); __restore_flags(flags); if (flags != flags2) panic("lock_kernel called with irq disabled");
Andrea Arcangeli
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |