BKM on generating a call graph for smatch warnings

BKM on generating a call graph for smatch warnings

[Reshetova, Elena]

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? 

Best Regards,
Elena.

Re: BKM on generating a call graph for smatch warnings

[Dan Carpenter]

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

RE: BKM on generating a call graph for smatch warnings

[Reshetova, Elena]

Hi Dan, 

Thank you very much, this helps greatly!

And no worries for delayed reply, I have not gotten to resolve this yet,
was busy with other things. Let me try this out!

Best Regards,
Elena.

> -----Original Message-----
> From: Dan Carpenter <dan.carpenter@oracle.com>
> Sent: Monday, September 13, 2021 6:10 PM
> To: Reshetova, Elena <elena.reshetova@intel.com>
> Cc: smatch@vger.kernel.org
> Subject: Re: BKM on generating a call graph for smatch warnings
> 
> 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