On Tue, Feb 20, 2024 at 02:39:35PM +0300, Dan Carpenter wrote: > 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 Well, the last time I tried smatch it wouldn't build out of box, and it took a solid day to figure out that it was an llvm version mismatch when I didn't seem to even need llvm. I'm not asking for distro packages here, but it'd be cool if I could integrate it into my own CI system. > 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. Why not just put this stuff up in a dashboard? Make it easy for people to see the full results for their code, without nagging them with a separate email for every warning? > fs/bcachefs/journal.c:575 __journal_res_get() error: uninitialized symbol 'can_discard'. your error message seems wrong to me. If it was an uninitialized _symbol_, i.e. that symbol didn't exist, then the code wouldn't build. Instead you seem to be warning about a possibly uninitialized variable. Yet a cursory inspection reveals the variable is initialized in every path before it's used, and gcc gets it right. > fs/bcachefs/alloc_background.c:1751 bch2_discard_one_bucket() warn: missing error code here? 'discard_in_flight_add()' failed. 'ret' = '0' No idea what smatch is complaining about here, we're returning either -EEXIST the error code of darray_push().
