Re: BKM on generating a call graph for smatch warnings

[Dan Carpenter <dan.carpenter@oracle.com>]

Hi,

I'm really sorry, I missed your email.  I was on vacation that week and
didn't see your email until now.

On Tue, Aug 17, 2021 at 07:32:21AM +0000, Reshetova, Elena wrote:
> Hi, 
> 
> Quick question: are there some suggested methods for obtaining a call graph
> for a warning that a smatch pattern reports when I run it for the whole kernel? 
> 
> I can see that there are a couple of existing patterns (check_capable, check_locking)
> that use sql methods for saving the caller_info, but I don't fully understand how it
> works, maybe there is some description somewhere on this that I missed? 

How the Smatch cross function database works is that you run:

	/path/to/smatch/smatch_scripts/build_kernel_data.sh

This takes a long time to run.  It does a complete Smatch run and it
outputs a ton of SQL insert commands.  Then it does:

	cat sql.txt | sqlite3 smatch_db.sqlite

It doesn't literally cat that because that would be very slow.  It's
uses a perl script to handle transactions, caching and syncing etc.
There is also a little bit of tweaking for some of the tables.  The
final database on my system is 30GB.

What I do is I rebuild my database every night.  Each time you rebuild
the database then the knowledge about the call tree gets pushed out one
call further.

In my experience if you rebuild the DB 5-7 times, that's basically
the limit.  The call tree is complete, of course, right away.  foo()
calls bar() calls baz().  But it takes two rebuilds before the user
data from foo() gets to baz().

The /path/to/smatch/smatch_data/db/smdb.py script is a way to see what's
stored in the database.  `smdb.py foo` will print all the callers of
foo() and `smdb.py return_states foo` will show what it returns.

Again, very sorry for the long delay.  Please let me know if you have
any questions.

regards,
dan carpenter