All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Drokin <green@whamcloud.com>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	"smatch@vger.kernel.org" <smatch@vger.kernel.org>,
	"Kleen, Andi" <andi.kleen@intel.com>
Subject: Re: Smatch mailing list archives
Date: Mon, 10 May 2021 14:13:30 +0000	[thread overview]
Message-ID: <F070A889-8B98-4723-9F05-1BC44C4051D6@whamcloud.com> (raw)
In-Reply-To: <CY4PR1101MB2326420B4935F1A3966C626BE7549@CY4PR1101MB2326.namprd11.prod.outlook.com>



> On May 10, 2021, at 5:31 AM, Reshetova, Elena <elena.reshetova@intel.com> wrote:
> 
>>> On May 10, 2021, at 2:17 AM, Reshetova, Elena <elena.reshetova@intel.com>
>> wrote:
>>> 
>>> What is the best way to create identifiers for the findings that certain smatch
>>> pattern finds in the kernel? Let's say I have a new pattern that is able to find
>>> different problematic places and report them in usual smatch way: errors and
>>> warnings with file name, line number, function name, etc.
>>> Now for our pattern in order to be sure that the reported issue exists/does not
>>> exists, somebody needs to go and look at the code manually and make a call.
>>> After this, it would be nice to mark this place as safe/concern in the report and be
>>> able to transfer these results for kernel versions bumps (5.11->5.12, etc.) as soon
>> as
>>> the code in this function where finding was reported has not changed (and there
>>> might be multiple findings per function).
>> 
>> When I was doing a similar thing to integrate smatch into gerrit, I decided that
>> line numbers are too unreliable a metric to really depend on.
>> Instead for most cases just using the rest of the message seems to be good enough?
>> Function name, whatever variable or the message there is and such is used to filter
>> out
>> known failures (two kinds: false positives and actual bugs that need to be fixed, but
>> are yet unfixed so no point in alerting people to them again and again on unrelated
>> review requests)
>> 
>> Seems to be working well though I am sure might not be super perfect.
> 
> I don't think this would be good enough for our case, since what we essentially looking 
> for with smatch is a set of function calls to a specific functions. So, I end up with 
> smth like:
> 
> drivers/vme/boards/vme_vmivme7805.c:69 vmic_probe() warn: read using function
> 'ioread32' to an int type local variable 'data', type is uint
> drivers/vme/boards/vme_vmivme7805.c:74 vmic_probe() warn: read using function
> 'ioread32' to an int type local variable 'data', type is uint
> 
> The two above items are in the same function vmic_probe(), making the same function
> call " ioread32" and writing down the result of this function call into the same var 'data'.
> They just happen to do this in two different places in vmic_probe function. 
> So, essentially they are even exactly the same lines in this case and the only difference is
> relative line position within the analyzed vmic_probe() function. 

So is your concern that one of those warnings might be a real bug while another one
is not? Because if they both are correct or both are incorrect seemingly
it does not matter (for filtering purposes) that you have two instead of one?


  reply	other threads:[~2021-05-10 14:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CY4PR1101MB2326F684A9371A12746211FFE7579@CY4PR1101MB2326.namprd11.prod.outlook.com>
2021-05-07 14:22 ` Smatch mailing list archives Reshetova, Elena
2021-05-08  5:16   ` Dan Carpenter
2021-05-10  6:17     ` Reshetova, Elena
2021-05-10  6:59       ` Oleg Drokin
2021-05-10  9:31         ` Reshetova, Elena
2021-05-10 14:13           ` Oleg Drokin [this message]
2021-05-11 13:40             ` Dan Carpenter
2021-05-11 14:10             ` Reshetova, Elena
2021-05-10  7:20       ` Dan Carpenter
2021-05-10  9:43         ` Reshetova, Elena

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=F070A889-8B98-4723-9F05-1BC44C4051D6@whamcloud.com \
    --to=green@whamcloud.com \
    --cc=andi.kleen@intel.com \
    --cc=dan.carpenter@oracle.com \
    --cc=elena.reshetova@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.