Messages in this thread |  | | | Date | Fri, 5 Jun 2009 15:52:07 +0200 | | Subject | Re: smatch 1.53 released | | From | Dan Carpenter <> |
| |
On 6/4/09, Andi Kleen <andi@firstfloor.org> wrote: > Thanks for the description. > >> So basically you grep for locking functions and you set the state >> based on that, then you grep for return statements and check that the > > When you say "you" you mean smatch is doing that on its own > or does the user need to do that manually? >
I meant if you were writing a check for a different type of bug. The checks that I mentioned are the ones I have written already.
There is also a line between the core smatch and the checks. The core understands code flow and the checks call set_state() and get_state() and print error messages. The core is able to handle any C code but the checks are project specific.
>> Many of the locking false positives come from places where the unlock >> happens in a seperate function. It should be relatively straight >> forward to make a list functions to say that if frob_the_module() >> returns -12, or -14 that implies it unlocked a certain lock. I >> haven't done this yet. > > How would one pass that list of functions to smatch? >
You can't right now. That's the bit that I still need to write. :/ But as an example, one of the checks has a file smatch_data/ with a list of functions that allocate memory. Locking functions would be the same.
> I understand correctly that right now it's not inter procedural in its > analysis? >
The null dereference check is, but none of the other checks are.
When the inter procedural analysis is done, it will mostly be a two pass system where the first step builds a list of functions and what they imply and the second pass does the check. Meaning two kernel compiles. Or more likely, people will just use the default lists which will be updated for -rc1 kernels.
Smatch is still in the very early stages.
regards, dan carpenter
> -Andi > > -- > ak@linux.intel.com -- Speaking for myself only. >
|  |