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
