----- Original Message -----
From: Dave Hansen <[email protected]>
Date: Tue, 09 Jul 2002 10:41:01 -0700
To: dan carpenter <[email protected]>
Subject: Re: lock_kernel check...
> dan carpenter wrote:
> > Smatch.pm is from the smatch.sf.net scripts page. Smatch is a
> > really unfinished code checker that I've been working on. It is
> > based on reading the papers about the Stanford checker.
>
> There was a time when I was thinking about the same thing. It kept
> scaring me the more I thought about it.
>
True. But someone is going to write a checker at some point. It's only a couple days work if you know what you are doing. There doesn't seem to be much advantage in waiting a year or two.
> > Unfortunately, after a night of sleep I realize that my script is
> > broken for 2 reasons. 1) Smatch.pm is meant to track state changes
> > down different code paths. But unfortunately it wasn't doing that
> > in this case; it was just going down the code without taking into
> > consideration any if_stmts etc. I'm extremely embarassed about
> > that. Sorry.
>
> Don't be sorry. The script is smarter than the people who caused the
> errors. (once again, probably me)
>
> > 2) What the Stanford checker does is print an error
> > if one return_stmt is called while the kernel is locked and one is
> > called while the kernel is unlocked. This seems reasonable.
>
> Could you clarify that a bit?
>
If someone made a mistake where they always returned under a kernel_lock() they would find the mistake themselves.
Why would they return under kernel_lock() on error, for example, but not on success? That would be confusing. There would still be some false positives but the number of cases is really small.
regards,
dan carpenter
--
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup
Save up to $160 by signing up for NetZero Platinum Internet service.
http://www.netzero.net/?refcd=N2P0602NEP8