From: "Reshetova, Elena" <elena.reshetova@intel.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "smatch@vger.kernel.org" <smatch@vger.kernel.org>
Subject: RE: BKM on generating a call graph for smatch warnings
Date: Tue, 14 Sep 2021 06:06:36 +0000 [thread overview]
Message-ID: <DM8PR11MB5701DE545C151DC38592175CE7DA9@DM8PR11MB5701.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20210913150933.GL7203@kadam>
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
prev parent reply other threads:[~2021-09-14 6:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-17 7:32 BKM on generating a call graph for smatch warnings Reshetova, Elena
2021-09-13 15:09 ` Dan Carpenter
2021-09-14 6:06 ` Reshetova, Elena [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DM8PR11MB5701DE545C151DC38592175CE7DA9@DM8PR11MB5701.namprd11.prod.outlook.com \
--to=elena.reshetova@intel.com \
--cc=dan.carpenter@oracle.com \
--cc=smatch@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).