Re: smatch 1.53 released

[Dan Carpenter <error27@gmail.com>]

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.
>