Re: Smatch mailing list archives

On Mon, May 10, 2021 at 06:17:27AM +0000, Reshetova, Elena wrote:
> > On Fri, May 07, 2021 at 02:22:37PM +0000, Reshetova, Elena wrote:
> > > Hi,
> > >
> > > I have been working for a while now on a new smatch pattern, but
> > > would really appreciate additional information points such as past
> > > email discussions, etc.
> > >
> > > So I am wondering if there is a way to browse through
> > > the archives of this mailing list in order to try to find the
> > > information I need?
> > 
> > Sorry, I don't think it's archived anywhere.  There isn't a lot of
> > traffic on the list.  About three times a year someone reports that
> > Smatch is crashing for them.
> > 
> > I'm always happy to answer questions if there is any way I can help?
> 
> Thank you Dan! I am pretty new with smatch so that's why I was
> hoping to browse through the existing mails to see if my simple questions
> are already answered, but here is my current issue. 
> 
> 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).
> 
> What is the best way of doing it? 
> I was first thinking of using some simple hash for the reported line (lines around, relative
> position within the reported function),
> but now I think I need also to hash the whole function in addition to the finding itself. 
> 
> Then the logic of transferring the result would be:
> 
> For each finding calculate: 
>  1. finding_line_hash: the hash of the line that resulted in finding (becomes a unique id
>      within the function).
> 2. finding_function_hash: the hash of the function that produced the finding (becomes a
>    unique global id within the kernel) and helps to determine if the function has not been
>    changed between the kernel versions. 
> 
> Logic for the result transfer: 
> 
> If both finding_line_hash and finding_function_hash match between the two smatch reports
> for two different versions, then it is relatively safe to transfer this concrete smatch finding
> and its manual audit result automatically.
> 
> Does it make sense overall? If yes, what is the easiest way in smatch to get hash data for 
> 1 and 2? I.e. get full reported line as a string and full function content as a string? 

I use the a script smatch_scripts/new_bugs.pl  It strips out the
variables names from the single quotes and any numbers and the
parentheses so it looks like this:

Original warning:

    fs/fuse/virtio_fs.c:1468 virtio_fs_get_tree() error: double free of 'fm'

Stripped:

    fs.fuse.virtio_fs.c.virtio_fs_get_tree_error:_double_free_of_''

You could hash the stripped string.  Looking at it now, the variable
name is actually useful and shouldn't be stripped out.  Doh...

I don't know what the zero day bot does for this to mark warnings as
dealt with or not.  There is also the Aiaiai project
(https://www.openhub.net/p/aiaiai) which probably has a feature for
marking warnings as reviewed.

regards,
dan carpenter