From: Dan Carpenter <dan.carpenter@linaro.org>
To: Oleg Drokin <green@linuxhacker.ru>
Cc: Dongliang Mu <dzm91@hust.edu.cn>,
Dan Carpenter <error27@gmail.com>,
HUST OS Kernel Contribution
<hust-os-kernel-patches@googlegroups.com>,
smatch@vger.kernel.org,
Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Subject: Re: List some ideas about Smatch as public projects in our open source club
Date: Tue, 24 Oct 2023 08:08:26 +0300 [thread overview]
Message-ID: <92c08d8e-d666-4ebd-ab56-a4844eed82dd@kadam.mountain> (raw)
In-Reply-To: <2d7010988a81f53e500a1940e95d17b450a0b052.camel@linuxhacker.ru>
On Mon, Oct 23, 2023 at 11:18:17AM -0400, Oleg Drokin wrote:
> On Mon, 2023-10-23 at 17:08 +0300, Dan Carpenter wrote:
> > After we make these two changes the bug is detected. It finds quite
> > a
> > few bugs that way. The MAYBE_FREED changes generate quite a few
> > false
> > positives so I haven't decided out how to deal with that yet...
>
> I think the way to deal with this is "whitelisting"?
> For any established project as you introduce new checks, there are
> going to be false positives.
> You run the check for the first time and (assuming you don't get a
> gazillion hits) then separate the results into "valid" and "invalid".
> Then the valid ones get patches and invalid ones are marked somehow
> (could be coverity-style markup, some external database or I am sure
> a number of other methods. For things I care about I keep a local
> database I filter things through).
> >From then on only new occurrences (result of code changes) will ever
> surface and get triaged the same way. And in this case even false
> positives might not be as bad.
Yeah. You're probably right. I had planned to investigate the warnings
and look at various stratagies to silence them on a case by case basis.
But a simpler, Big Hammer, approach would be to just create a list of
param/key pairs which cancel out a MAYBE_FREE.
> If we remember the original coverity paper (that also was when the
> original smatch was inspired I think), they have a very astute
> observation that "sure, there are false positives, but as we were
> investigating them we found other bugs. So if your code is confusing
> enough to throw off analysis tools off, it's likely confusing enough to
> host bugs of some kind anyway".
> Sadly I think the focus shifted a lot since then into "as few of false
> positives as possible" and other such pie in the sky matters (not to
> say some sort of balance is not important of course).
I still write the same code as always, I just tend to not publish it.
But it might be fun to just publish everything. A lot of stuff is
half finished. I have an idea and test it, but the results are bad and
I never make it actually work. Or sometimes I don't know how to make it
work but I still leave the code until later.
I'm generally bad at pushing code. I write it and then forget about it.
:/
The other thing about false positives is that --spammy is supposed to be
more false positive prone and --pedantic is used for style issues. The
--pedantic option isn't used very much now but in my head maybe it will
be in the future. I should probably rename it to --style.
One of the bad things about the original Smatch was that I was crap at
merging other people's code. These days I tend to merge everything that
people send.
regards,
dan carpenter
prev parent reply other threads:[~2023-10-24 5:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <a785af32-78ba-4c3c-afe5-6f96128c3c2a@hust.edu.cn>
2023-10-23 14:08 ` List some ideas about Smatch as public projects in our open source club Dan Carpenter
2023-10-23 15:18 ` Oleg Drokin
2023-10-24 5:08 ` Dan Carpenter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=92c08d8e-d666-4ebd-ab56-a4844eed82dd@kadam.mountain \
--to=dan.carpenter@linaro.org \
--cc=dzm91@hust.edu.cn \
--cc=error27@gmail.com \
--cc=green@linuxhacker.ru \
--cc=harshit.m.mogalapalli@oracle.com \
--cc=hust-os-kernel-patches@googlegroups.com \
--cc=smatch@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).