From: "Lukas Bulwahn" <lukas.bulwahn@gmail.com>
To: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
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 16:11:38 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.2010121550300.6487@felia> (raw)
In-Reply-To: <20201011205008.24369-1-sudipm.mukherjee@gmail.com>
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.
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.
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.
We encountered this issue because of clang analyzer complaining, but it is
clear that it is a false positive of that (smart but) incomplete tool.
Do you intend to add comment for all false positives from all tools or are
we going to find a better solution than that?
I am happy to contribute to the smarter solution...
e.g., a cocci script that checks that the call is still there and then
always marking the related tool finding as false positive.
Lukas
> ---
> drivers/usb/host/ehci-sched.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
> index 6dfb242f9a4b..0f85aa9b2fb1 100644
> --- a/drivers/usb/host/ehci-sched.c
> +++ b/drivers/usb/host/ehci-sched.c
> @@ -244,6 +244,12 @@ static void reserve_release_intr_bandwidth(struct ehci_hcd *ehci,
>
> /* FS/LS bus bandwidth */
> if (tt_usecs) {
> + /*
> + * find_tt() will not return any error here as we have
> + * already called find_tt() before calling this function
> + * and checked for any error return. The previous call
> + * would have created the data structure.
> + */
> tt = find_tt(qh->ps.udev);
> if (sign > 0)
> list_add_tail(&qh->ps.ps_list, &tt->ps_list);
> @@ -1337,6 +1343,12 @@ static void reserve_release_iso_bandwidth(struct ehci_hcd *ehci,
> }
> }
>
> + /*
> + * find_tt() will not return any error here as we have
> + * already called find_tt() before calling this function
> + * and checked for any error return. The previous call
> + * would have created the data structure.
> + */
> tt = find_tt(stream->ps.udev);
> if (sign > 0)
> list_add_tail(&stream->ps.ps_list, &tt->ps_list);
> --
> 2.11.0
>
>
>
>
>
>
>
next prev parent reply other threads:[~2020-10-12 14:11 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 ` Lukas Bulwahn [this message]
2020-10-12 14:57 ` [linux-safety] " Alan Stern
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=alpine.DEB.2.21.2010121550300.6487@felia \
--to=lukas.bulwahn@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-safety@lists.elisa.tech \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--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