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
[email protected]
On Tue, 2002-07-09 at 07:44, Dave Hansen wrote:
> The Stanford Checker or something resembling it would be invaluable
> here. It would be a hell of a lot better than my litle patch!
The Stanford Checker would be infinitely invaluable here -- agreed.
Anything that can graph call chains and do analysis... we can get it to
tell us exactly who and what.
Robert Love
Em Tue, Jul 09, 2002 at 02:47:49PM -0700, Robert Love escreveu:
> On Tue, 2002-07-09 at 07:44, Dave Hansen wrote:
>
> > The Stanford Checker or something resembling it would be invaluable
> > here. It would be a hell of a lot better than my litle patch!
>
> The Stanford Checker would be infinitely invaluable here -- agreed.
>
> Anything that can graph call chains and do analysis... we can get it to
> tell us exactly who and what.
Try smatch:
http://smatch.sf.net
And see if you can write a smatch script to get a good broom for this trash 8)
- Arnaldo
On Tue, 9 Jul 2002, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jul 09, 2002 at 02:47:49PM -0700, Robert Love escreveu:
> > On Tue, 2002-07-09 at 07:44, Dave Hansen wrote:
> >
> > > The Stanford Checker or something resembling it would be invaluable
> > > here. It would be a hell of a lot better than my litle patch!
> >
> > The Stanford Checker would be infinitely invaluable here -- agreed.
> >
> > Anything that can graph call chains and do analysis... we can get it to
> > tell us exactly who and what.
Not anything. It can be used to find problems (and be very helpful at that)
but it can't be used to verify anything.
The problem is that checker doesn't (and cannot) cover all code paths -
by the time when it comes into the game the source had already passed
through through cpp. In other words, depending on the configuration
you might get very different results.
Normally it's not that bad, but "can this function block?" is very nasty
in that respect - changes of configuration can and do affect that in
non-trivial ways. Checker can be _very_ useful since it allows to catch
some of the existing bugs, but it should not be used as a justification
of change that might introduce bugs if some assumption ever becomes false.
> Try smatch:
>
> http://smatch.sf.net
>
> And see if you can write a smatch script to get a good broom for this trash 8)