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
