linux-kernel - Re: sparse annotation for error types?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sat, 19 Dec 2020 14:55:01 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Zhang Changzhong <zhangchangzhong@...wei.com>
Cc:     linux-sparse@...r.kernel.org, linux-kernel@...r.kernel.org,
        edwin.peer@...adcom.com
Subject: Re: sparse annotation for error types?

I've pushed my Smatch check for missing error codes.

https://github.com/error27/smatch/commit/be18f90f05b684c12b80b9364b5bbc5dbef922da

I ended up writing a slightly more tricky version of the check because
there were some places that do:

		ret = 0;
		goto out;

And I didn't want to generate a warning for those.  The heuristic is
that if "ret" is up to 3 lines before the goto then it's probably
intentional.  There are still some false positives, especially in fs/
where "ret" is set to zero at the start of the function but it's
inentional.

I considered doing some more checking to say "this is an error path" but
I kind of like it as is.  I have a separate unpublished check for
"this is an error path and there is a goto but the error code is not set"
and I will probably fix that up and publish it as well.  So it will be
two warnings.  :)  Or vs And.

I've also attached the generated warnings from Friday's linux-next if
you want to take a look.

regards,
dan carpenter

View attachment "err-list" of type "text/plain" (11312 bytes)