public inbox for smatch@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@linaro.org>
To: Oleg Drokin <green@linuxhacker.ru>
Cc: Toomas Soome <tsoome@me.com>, smatch@vger.kernel.org
Subject: Re: apparent bug about check_free_strict
Date: Wed, 26 Nov 2025 15:14:07 +0300	[thread overview]
Message-ID: <aSbvD_1idd0csCqi@stanley.mountain> (raw)
In-Reply-To: <29167bc23b32a76180a3f0acd60483a95e282859.camel@linuxhacker.ru>

On Tue, Nov 25, 2025 at 10:34:49AM -0500, Oleg Drokin wrote:
> On Tue, 2025-11-25 at 17:04 +0200, Toomas Soome wrote:
> > For positive side, the current smatch has been able to detect many
> > bugs the previous versions had missed - its definitely good progress.
> > While there are some issues, we can disable checks on such cases.
> > Only problem is that where previously —disable=check_free_strict did
> > work, —disable=check_free does not seem to:)
> 
> The way I found to be the most impactful is to just keep a database of
> the warnings and then:
> 1. mark the clearly invalid ones so they don't pop up again
> 2. every time there's a new patch - see if anything new gets added.
> 
> the new additions are the primary focus of new triage then since all
> the old ones were presumably checked already.

Yeah.  This is my favorite approach too.

I feel like you're more in favour of a higher false positive ratio
than I am, but I do think looking at false positives one time only
and then ignoring it forever is the best approach.  It lets you check
for more things, faster.

regards,
dan carpenter


  reply	other threads:[~2025-11-26 12:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-18 11:55 apparent bug about check_free_strict Toomas Soome
2024-11-18 12:52 ` Dan Carpenter
2024-11-18 13:28   ` Toomas Soome
2024-11-18 15:27     ` Dan Carpenter
     [not found]       ` <ADB0555A-8DE4-49D1-B769-A02EB82690A9@me.com>
2025-11-21 18:01         ` Toomas Soome
2025-11-24 14:46           ` Dan Carpenter
2025-11-24 15:30             ` Toomas Soome
2025-11-25 13:38               ` Toomas Soome
2025-11-25 14:28                 ` Toomas Soome
2025-11-25 14:50                   ` Dan Carpenter
2025-11-25 15:04                     ` Toomas Soome
2025-11-25 15:34                       ` Oleg Drokin
2025-11-26 12:14                         ` Dan Carpenter [this message]
2025-11-25 17:12                       ` Dan Carpenter
     [not found]                     ` <32FD91B6-32B3-45FC-A6E5-EA39439466E3@me.com>
2025-11-26 15:12                       ` Dan Carpenter
     [not found]               ` <45D1224C-6C4C-4745-9FA6-F07BB1792831@me.com>
2025-11-25 13:50                 ` Dan Carpenter
2025-11-25 13:40         ` Dan Carpenter

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=aSbvD_1idd0csCqi@stanley.mountain \
    --to=dan.carpenter@linaro.org \
    --cc=green@linuxhacker.ru \
    --cc=smatch@vger.kernel.org \
    --cc=tsoome@me.com \
    /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