lkml.org 
[lkml]   [1999]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.072 / U:21.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site