Message-ID: <alpine.DEB.2.21.2010122008370.17866@felia>
Date:   Mon, 12 Oct 2020 20:17:34 +0200 (CEST)
From:   Lukas Bulwahn <lukas.bulwahn@...il.com>
To:     Alan Stern <stern@...land.harvard.edu>
cc:     Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, linux-safety@...ts.elisa.tech,
        linux-usb@...r.kernel.org
Subject: Re: [linux-safety] [PATCH] usb: host: ehci-sched: add comment about
 find_tt() not returning error



On Mon, 12 Oct 2020, Alan Stern wrote:

> On Mon, Oct 12, 2020 at 05:10:21PM +0200, Lukas Bulwahn wrote:
> > 
> > 
> > On Mon, 12 Oct 2020, Alan Stern wrote:
> > > Real code contains so many assumptions, especially if you include ones 
> > > which are obvious to everybody, that such a tool seems impractical.
> > >
> > 
> > I fear that problem applies to all static code analysis tools I have seen; 
> > at some point, the remaining findings are simply obviously wrong to 
> > everybody but the tool does not get those assumptions and continues 
> > complaining, making the tool seem impractical.
> 
> Indeed, it is well known that the problem of finding all errors or bugs 
> by static code analysis is Turing complete.
> 
> > Alan, so would you be willing to take patches where _anyone_ simply adds 
> > comments on what functions returns, depending on what this person might 
> > consider just not obvious enough?
> 
> No.  I would take such patches from anyone, but depending on what _I_ 
> consider not obvious enough.
> 
> > Or are you going to simply reject this 'added a comment' patch here?
> 
> I have already accepted it.  In fact, the patch was my suggestion in the 
> first place.
> 
> When I originally wrote this code, I was aware that it was somewhat 
> subtle, but at the time it didn't seem to warrant a comment or 
> explanation.  Sudip's patch has changed my mind.
> 
> > I am not arguing either way, it is just that it is unclear to me what the 
> > added value of the comment really is here.
> 
> As with many other comments, its purpose is to explain a somewhat 
> obscure aspect of the code -- something which is there by design but 
> isn't immediately obvious to the reader.  That is the added value.
>

Fine, then I was more conservative on adding comments than you; we will 
see if other maintainers accept adding such comments as well for further 
findings we will encounter.
 
> > And for the static analysis finding, we need to find a way to ignore this 
> > finding without simply ignoring all findings or new findings that just 
> > look very similar to the original finding, but which are valid.
> 
> Agreed.  In this case, the new comment does a pretty good job of telling 
> people using the tool that the finding is unjustified.
> 
> If you are suggesting some sort of special code annotation that the tool 
> would understand, I am open to that.  But I'm not aware of any even 
> vaguely standard way of marking up a particular function call to 
> indicate it will not return an error.
>

I cannot yet say if some annotation would work, we, Sudip and me, need to 
investigate. It could be that something like, assert(!IS_ERR(tt)), is 
sufficient to let the tools know that they can safely assume that the 
path they are complaining about is not possible.

We could make the assert() a nop, so it would not effect the resulting 
object code in any way.

We have not tried that; We are still experimenting with clang analyzer 
and are still learning.

Lukas

Powered by blists - more mailing lists