Message-ID: <d3b63d25-1b03-4c7c-85cc-efd9d74c3a8a@suswa.mountain>
Date: Thu, 7 Aug 2025 10:22:05 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Stefan Metzmacher <metze@...ba.org>
Cc: Steve French <sfrench@...ba.org>, Paulo Alcantara <pc@...guebit.org>,
	Ronnie Sahlberg <ronniesahlberg@...il.com>,
	Shyam Prasad N <sprasad@...rosoft.com>, Tom Talpey <tom@...pey.com>,
	Bharath SM <bharathsm@...rosoft.com>, linux-cifs@...r.kernel.org,
	samba-technical@...ts.samba.org, linux-kernel@...r.kernel.org,
	kernel-janitors@...r.kernel.org,
	Namjae Jeon <linkinjeon@...nel.org>
Subject: Re: Using smatch and sparse together (Re: [PATCH next] smb: client:
 Fix use after free in send_done())

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

Powered by blists - more mailing lists