Re: Using smatch and sparse together (Re: [PATCH next] smb: client: Fix use after free in send_done())

[Stefan Metzmacher <metze@samba.org>]

Am 07.08.25 um 09:22 schrieb Dan Carpenter:
> 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:

This seems to work for me now:

$ cat custom-checker.sh
#!/bin/bash

set -e

which sparse > /dev/null 2>&1 && {
         sparse -Winit-cstring -Wsparse-error -fdiagnostic-prefix=SPARSE $@
}

which smatch > /dev/null 2>&1 && {
         smatch -p=kernel --pedantic --succeed $@
}

$ cat build-fs-smb.sh
#!/bin/bash
#

set -ueo pipefail

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" $@ 2>&1 | tee build-fs-smb.out

cat build-fs-smb.out | grep -v 'parse error: Function too hairy' | grep -q 'error:' || {
         rm build-fs-smb.out
         exit 0
}
echo ""
echo "BUILD-ERRORS:"
cat build-fs-smb.out | grep -v 'parse error: Function too hairy' | grep 'error:'
find fs/smb -name '*.o' | xargs rm
find fs/smb -name '*.ko' | xargs rm
rm build-fs-smb.out
exit 1


> 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.

Ok, what's the gain of updating it?
Does it help when doing fixes on old kernels?

I'm typically doing a full kernel build a week after each rc.
My idea was to rebuild the whole db after doing that.

Thanks!
metze