linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, linux-safety@lists.elisa.tech,
	linux-usb@vger.kernel.org
Subject: Re: [linux-safety] [PATCH] usb: host: ehci-sched: add comment about find_tt() not returning error
Date: Mon, 12 Oct 2020 10:57:10 -0400	[thread overview]
Message-ID: <20201012145710.GA631710@rowland.harvard.edu> (raw)
In-Reply-To: <alpine.DEB.2.21.2010121550300.6487@felia>

On Mon, Oct 12, 2020 at 04:11:38PM +0200, Lukas Bulwahn wrote:
> 
> 
> On Sun, 11 Oct 2020, Sudip Mukherjee wrote:
> 
> > Add a comment explaining why find_tt() will not return error even though
> > find_tt() is checking for NULL and other errors.
> > 
> > Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
> 
> I get the intent of the comment but there is a large risk that somebody 
> could remove the find_tt() call before the calling the function and there 
> is no chance to then see later that the comment is actually wrong.

Why would anybody do that?  Who would deliberately go change a driver in 
a way that is obviously wrong and would break it?  Especially when such 
changes are likely to cause compile errors?

There are tons of changes one might make to any program that will leave 
it syntactically valid but will cause it to fail.  What's special about 
removing the early calls to find_tt()?

> I guess you want to link this comment here to a code line above and
> request anyone touching the line above to reconsider the comment then.

That really seems unnecessary.

> But there is no 'concept' for such kind of requests to changes and 
> comments.
> 
> So, the comment is true now, but might be true or wrong later.
> 
> I am wondering if such comment deserves to be included if we cannot check 
> its validity later...
> 
> I would prefer a simple tool that could check that your basic assumption 
> on the code is valid and if it the basic assumption is still valid, 
> just shut up any stupid tool that simply does not get that these calls 
> here cannot return any error.

Real code contains so many assumptions, especially if you include ones 
which are obvious to everybody, that such a tool seems impractical.

Alan Stern

  reply	other threads:[~2020-10-12 14:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-11 20:50 [PATCH] usb: host: ehci-sched: add comment about find_tt() not returning error Sudip Mukherjee
2020-10-12  0:27 ` Alan Stern
2020-10-12 14:11 ` [linux-safety] " Lukas Bulwahn
2020-10-12 14:57   ` Alan Stern [this message]
2020-10-12 15:10     ` Lukas Bulwahn
2020-10-12 15:18       ` Greg Kroah-Hartman
2020-10-12 18:25         ` Lukas Bulwahn
2020-10-13  5:23           ` Greg Kroah-Hartman
2020-10-13  5:37             ` Lukas Bulwahn
2020-10-13  6:36               ` Greg Kroah-Hartman
2020-10-13  7:16                 ` Lukas Bulwahn
2020-10-13  7:35                   ` Greg Kroah-Hartman
2020-10-13  8:02                     ` Lukas Bulwahn
2020-10-13  8:24               ` Sudip Mukherjee
2020-10-13  8:36                 ` Lukas Bulwahn
2020-10-12 16:00       ` Alan Stern
2020-10-12 18:17         ` Lukas Bulwahn
2020-10-13  5:21           ` Greg Kroah-Hartman
2020-10-13  5:41             ` Lukas Bulwahn
2020-10-12 15:24   ` Sudip Mukherjee
2020-10-12 18:49     ` Lukas Bulwahn

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=20201012145710.GA631710@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-safety@lists.elisa.tech \
    --cc=linux-usb@vger.kernel.org \
    --cc=lukas.bulwahn@gmail.com \
    --cc=sudipm.mukherjee@gmail.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;
as well as URLs for NNTP newsgroup(s).