On Thu, Aug 07, 2025 at 08:34:09AM +0200, Stefan Metzmacher wrote: > Am 06.08.25 um 16:39 schrieb Dan Carpenter: > > On Wed, Aug 06, 2025 at 04:17:41PM +0200, Stefan Metzmacher wrote: > > > > > What was the test that triggered the problem? > > > > > Or did you only noticed it by looking at the code? > > > > > > > > This was a Smatch static checker warning. You need to have the cross > > > > function DB to detect it. > > > > > > Ok, I'll try to integrate it into my build flow... > > > > > > Does it replace sparse or does it run in addition? > > > > In addition. I find the Sparse endianness checks especially useful. > > > > > If it replaces sparse I guess a small script would > > > run them both? > > > > > > $ cat mychecker.sh: > > > #!/bin/bash > > > set -e > > > sparse $@ > > > smatch $@ > > > > > > And maybe all others from > > > https://gautammenghani.com/linux,/c/2022/05/19/static-analysis-tools-linux-kernel.html > > I'm using this now: > > $ cat custom-checker.sh > #!/bin/bash > > set -e > > which sparse > /dev/null 2>&1 && { > sparse -Winit-cstring -Wsparse-error $@ > } > > which smatch > /dev/null 2>&1 && { > smatch -p=kernel --fatal-checks $@ I would say don't do fatal checks... I don't love that option at all. It was for another project which limits which checks it enables. > } > > $ cat build-fs-smb.sh > make modules_prepare > make -j16 M=fs/smb CF=-D__CHECK_ENDIAN__ W=1ce C=1 KBUILD_MODPOST_WARN=1 KCFLAGS="-Wfatal-errors" CHECK="$(pwd)/custom-checker.sh" $@ > > > I'm currently getting these warnings: > > client/sess.c:436 cifs_chan_update_iface() warn: iterator used outside loop: 'iface' > client/sess.c:444 cifs_chan_update_iface() warn: iterator used outside loop: 'iface' This code is fine. It's quite hard for Smatch to parse if (list_entry_is_head(iface, &ses->iface_list, iface_head)) { correctly. > client/inode.c:1703 cifs_root_iget() warn: passing zero to 'ERR_PTR' Huh... This warning showed up in 2023 and I didn't report it. I probably should have. fs/smb/client/inode.c 1693 iget_root: 1694 if (!rc) { 1695 if (fattr.cf_flags & CIFS_FATTR_JUNCTION) { 1696 fattr.cf_flags &= ~CIFS_FATTR_JUNCTION; 1697 cifs_autodisable_serverino(cifs_sb); 1698 } 1699 inode = cifs_iget(sb, &fattr); Should this have been: inode = cifs_iget(sb, &fattr); if (!inode) rc = -EINVAL; 1700 } 1701 1702 if (!inode) { 1703 inode = ERR_PTR(rc); 1704 goto out; 1705 } > client/inode.c:2295 cifs_mkdir() warn: passing zero to 'ERR_PTR' Returning ERR_PTR(0) means reporting NULL and it's an idiom in fs/. But outside of fs/ then most times it is a bug. So the warning is useful, but in fs/ it's often deliberate like it is here. > server/smb2pdu.c:3754 smb2_open() warn: Function too hairy. No more merges. > server/smb2pdu.c:3754 smb2_open() parse error: Function too hairy. Giving up. 18 seconds > Yeah. Ignore these. > Is there a way to use --fatal-checks but turn the 'too hairy' and maybe others into a warning only? > Something like -Wno-error=... in gcc. Yeah. Let me disable those unless --spammy is enabled. They're for debugging only and I'm probably the only person who is interested in them. > > Or at least turn this into an error: > client/smbdirect.c:292 send_done() error: dereferencing freed memory 'request' (line 290) > Without --fatal-checks smatch still returns 0. > Sure. To be honest, I normally build with the --succeed option which is the opposite of --fatal-checks. > While this returns an error (without --fatal-checks): > server/smb2pdu.c:3754 smb2_open() warn: Function too hairy. No more merges. > server/smb2pdu.c:3754 smb2_open() parse error: Function too hairy. Giving up. 8 seconds > > Currently I typically use git rebase -i and then have some like this > > exec bash build-fs-smb.sh C=0 > pick 123456 my first patch > exec bash build-fs-smb.sh > pick 654321 my 2nd patch > exec bash build-fs-smb.sh > > So I force C=0 on the initial run in order to avoid hitting the fatal Function too hairy > and it then works with my default of C=1 if I don't change fs/smb/server/smb2pdu.c > (or with --fatal-checks and other file that has a warning) > > I'd actually prefer to use --fatal-checks and C=1 in all cases > in order to notice problems I'm introducing... I use the scripts/new_bugs.pl script. After I've looked at the day's warnings then I run `scripts/new_bugs.pl --store err-list` and only review them again when I modify a file. > > > > How often do I need to run smatch_scripts/build_kernel_data.sh on the whole kernel? > > > > The cross function database is really useful for just information > > purposes and looking at how functions are called. You probably > > would need to rebuild it four or five times to get useful > > information, unfortunately. I rebuild my every night on the latest > > linux-next. > > I have the following files generated on a fast machine: > > $ ls -alrt smatch_* > -rw-r----- 1 metze metze 303104 Aug 6 15:42 smatch_db.sqlite.new > -rw-rw-r-- 1 metze metze 3107065 Aug 6 16:37 smatch_compile.warns > -rw-rw-r-- 1 metze metze 2848012813 Aug 6 16:37 smatch_warns.txt > -rw-rw-r-- 1 metze metze 6016192672 Aug 6 16:38 smatch_warns.txt.sql > -rw-rw-r-- 1 metze metze 4202917492 Aug 6 16:39 smatch_warns.txt.caller_info > -rw-r--r-- 1 metze metze 8757637120 Aug 6 16:57 smatch_db.sqlite > Your DB is 8GB. If you rebuild it enough times, then eventually the DB will max out at 32GB. If it gets to be over 40GB then my builds stop finishing in one night so I investigate and shrink it again... It's a cycle of adding code until things slow down too much and then optimizing it to make it bearable again. > I copied them all to my laptop where I develop my patches > and was able to reproduce the error :-) > > Do I need copy all of these or is smatch_db.sqlite enough? Yep. Only smatch_db.sqlite. I should probably delete the other files after the DB has been built. > > Would it be possible that you share your generated file(s) > via a download, that might be useful for a lot of people. > The DB is too big and too dependent on your .config but I should share the smatch_data/ more regularly. I started to push that into a separate git repo but I didn't finish that work. I should do that. regards, dan carpenter
