From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, cgel.zte@gmail.com
Cc: Mathias Nyman <mathias.nyman@intel.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
luo penghao <luo.penghao@zte.com.cn>,
Zeal Robot <zealci@zte.com.cn>
Subject: Re: [PATCH linux] usb: xhci-ring: Add return if ret is less than 0
Date: Thu, 30 Dec 2021 15:31:52 +0200 [thread overview]
Message-ID: <a740545a-b2cc-d829-8d63-6f0dc5ef6f8f@linux.intel.com> (raw)
In-Reply-To: <Yc1ZaOsmoZHoWyxt@kroah.com>
On 30.12.2021 9.02, Greg Kroah-Hartman wrote:
> On Thu, Dec 30, 2021 at 06:40:10AM +0000, cgel.zte@gmail.com wrote:
>> From: luo penghao <luo.penghao@zte.com.cn>
>>
>> For the robustness of the code, judgment and return should be added here
>
> I do not understand this changelog text at all. Please explain the
> problem and why you are making this change much better.
>
Agree, this doesn't explain at all what is going on.
So looking at the code it checks if a zero-length transfer after a bulk transfer is
properly prepared before queuing the TRB to hardware.
Nothing wrong with that. We do check that the main part of the bulk transfer
is properly prepared before this, so it's very unlikely to fail, but not impossible.
>>
>> The clang_analyzer complains as follows:
>>
>> drivers/usb/host/xhci-ring.c:
>>
>> Value stored to 'ret' is never read
>>
>> Reported-by: Zeal Robot <zealci@zte.com.cn>
>> Signed-off-by: luo penghao <luo.penghao@zte.com.cn>
>> ---
>> drivers/usb/host/xhci-ring.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
>> index d0b6806..c4eefe2 100644
>> --- a/drivers/usb/host/xhci-ring.c
>> +++ b/drivers/usb/host/xhci-ring.c
>> @@ -3721,6 +3721,8 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
>> ret = prepare_transfer(xhci, xhci->devs[slot_id],
>> ep_index, urb->stream_id,
>> 1, urb, 1, mem_flags);
>> + if (unlikely(ret < 0))
>> + return ret;
We can't just return if it fails.
We already queued the main part of the bulk transfer to the ring, but haven't given
those TRBs to hardware yet. This is done in giveback_first_trb() a few lines later.
As this case probably won't happen, we could just add a small debug message here,
and skip the zero-length packet.
Queue the main part of the bulk transfer and give it to hardware anyway.
It will probably time out later.
>> urb_priv->td[1].last_trb = ring->enqueue;
>> urb_priv->td[1].last_trb_seg = ring->enq_seg;
>> field = TRB_TYPE(TRB_NORMAL) | ring->cycle_state | TRB_IOC;
>> --
>> 2.15.2
>>
>>
>
> How did you test this change?
Wondering the same.
Suggestion:
Add a hack to detect a zero-length transfer in prepare_transfer(), and intentionally
fail (return error) in places prepare_transfer() could normally fail.
And then check that the system behaves better with your patch than without.
-Mathias
prev parent reply other threads:[~2021-12-30 13:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-30 6:40 [PATCH linux] usb: xhci-ring: Add return if ret is less than 0 cgel.zte
2021-12-30 7:02 ` Greg Kroah-Hartman
2021-12-30 13:31 ` Mathias Nyman [this message]
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=a740545a-b2cc-d829-8d63-6f0dc5ef6f8f@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=cgel.zte@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=luo.penghao@zte.com.cn \
--cc=mathias.nyman@intel.com \
--cc=zealci@zte.com.cn \
/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