lkml.org 
[lkml]   [2002]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: BKL removal
Robert Love wrote:
> On Tue, 2002-07-09 at 07:19, Dave Hansen wrote:
>
>>Robert Love wrote:
>>
>>>The problem is, it is needed in a _lot_ of places. Mostly instances
>>>where the lock is held across something that may implicitly sleep.
>>
>>And _that_ is why I wrote the BKL debugging patch, to help find these
>>places at runtime. It may not be pretty, but it works. I'll post it
>>again if you're interested.
>
> I saw the patch... the problem is we cannot say "oh I ran this code path
> with the patch and did not see anything, it is safe". Can sleep != will
> sleep, and thus we have code that 99% will not sleep but it may.

That's a good point, but we have to start somewhere. I think this is
a reasonable way to start looking for bad behavior. Since you have to
fix all of them anyway, why not let the easy bunch come to you instead
of seeking them out? In a couple of kernel versions, I'd like to make
it a BUG() to use the BKL in a nested fashion, or hold it during a
schedule. I think that his would be a reasonable thing to do during
the early days of the first development series after we think we have
this thing licked. But, that is admittedly ages from now in kernel
time.

The Stanford Checker or something resembling it would be invaluable
here. It would be a hell of a lot better than my litle patch!

--
Dave Hansen
haveblue@us.ibm.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.304 / U:0.012 seconds]
©2003-2011 Jasper Spaans. Advertise on this site