lock_kernel check...
----- 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...
Quoted 8 lines
Quoted 3 lines · dan carpenter
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.
Quoted 7 lines
Quoted 6 lines
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_stmtsetc. I'm extremely embarassed about that. Sorry.
Quoted 9 lines
Don't be sorry. The script is smarter than the people who caused the errors. (once again, probably me)
Quoted 3 lines
2) What the Stanford checker does is print an error
if onereturn_stmtis 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
Signature · 6 lines
__________________________________________________________ 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