On Thu, Feb 01, 2024 at 05:45:38AM -0500, Kent Overstreet wrote: > Smatch would be more useful to me if I could just run it myself, in my > own CI, and get results back for new code when I get the rest of my test > results, instead of getting yanked out of my flow a week later to go > abck and look at code I thought I was done with. Programming Smatch is quite difficult but running Smatch is fairly easy. It's documented in Documentation/smatch.txt. To test the kernel it's just: ~/path/to/smatch/smatch_scripts/test_kernel.sh Or to just test the parts you are interested in the it's: ~/path/to/smatch/smatch_scripts/kchecker fs/bcachefs/ To build the database takes maybe six hours but it's also easy enough. ~/path/to/smatch/smatch_scripts/build_kernel_data.sh The main issue is that I'm always writting new code. And sometimes that code is bad. Or sometimes I'm using a heuristic to find buggy code and it works but not well enough to publish. For example code like: if (!ret) return ret; I would estimate that in new code that's going to be buggy 5-10% of the time. (Obviously after we fix the bugs it's 100% false positives). I review code like this but I try to avoid publishing checks where there is a more than 50% false positive rate. So right now I only have two bcache warnings. The missing error code warning isn't published unfortunately... I don't think I'm going to have a lot of time to dedicate to this stuff in the up coming months honestly. fs/bcachefs/journal.c:575 __journal_res_get() error: uninitialized symbol 'can_discard'. fs/bcachefs/alloc_background.c:1751 bch2_discard_one_bucket() warn: missing error code here? 'discard_in_flight_add()' failed. 'ret' = '0' regards, dan carpenter
