From: Oliver Neukum <oneukum@suse.com>
To: Alan Stern <stern@rowland.harvard.edu>,
liulongfang <liulongfang@huawei.com>
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] USB:bugfix a controller halt error
Date: Thu, 27 Jul 2023 17:31:41 +0200 [thread overview]
Message-ID: <e983fecd-ff59-e97e-0099-b33685d45d00@suse.com> (raw)
In-Reply-To: <73b58ff7-2a0a-43f7-bda9-52b9437f5bc0@rowland.harvard.edu>
On 27.07.23 16:42, Alan Stern wrote:
> On Thu, Jul 27, 2023 at 03:03:57PM +0800, liulongfang wrote:
>> On 2023/7/26 22:20, Alan Stern wrote:
>>> It seems to me that something along these lines must be necessary in
>>> any case. Unless the bad memory is cleared somehow, it would never be
>>> usable again. The kernel might deallocate it, then reallocate for
>>> another purpose, and then crash when the new user tries to access it.
>>>
>>> In fact, this scenario could still happen even with your patch, which
>>> means the patch doesn't really fix the problem.
I suppose in theory you could have something like a bad blocks list
just for RAM, but that would really hurt. You'd have to do something
about every DMA operation in every driver in theory.
Error handling would basically be an intentional memory leak.
>> This patch is only used to prevent data in the buffer from being accessed.
>> As long as the data is not accessed, the kernel does not crash.
>
> I still don't understand. You haven't provided nearly enough
> information. You should start by answering the questions that Oliver
> asked. Then answer this question:
>
> The code you are concerned about is this:
>
> r = usb_control_msg(udev, usb_rcvaddr0pipe(),
> USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
> USB_DT_DEVICE << 8, 0,
> buf, GET_DESCRIPTOR_BUFSIZE,
> initial_descriptor_timeout);
> switch (buf->bMaxPacketSize0) {
>
> You're worried that if an ECC memory error occurs during the
> usb_control_msg transfer, the kernel will crash when the "switch"
> statement tries to read the value of buf->bMaxPacketSize0. That's a
> reasonable thing to worry about.
Albeit unlikely. If the hardware and implementation are reasonable
you'd return a specific error code from the HCD and clean up the
RAM in your ecc driver.
The fix for USB would then conceptually be something like
retryio:
r = usb_control_msg()
if (r == -EMEMORYCORRUPTION)
goto retryio;
Regards
Oliver
next prev parent reply other threads:[~2023-07-27 15:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-21 10:00 [PATCH] USB:bugfix a controller halt error liulongfang
2023-07-21 11:08 ` Greg KH
2023-07-26 6:44 ` liulongfang
2023-07-26 7:18 ` Greg KH
2023-07-26 11:16 ` Oliver Neukum
2023-07-27 7:00 ` liulongfang
2023-07-27 8:46 ` Oliver Neukum
2023-07-27 4:02 ` liulongfang
2023-07-21 14:57 ` Alan Stern
2023-07-24 12:35 ` Oliver Neukum
2023-07-26 6:58 ` liulongfang
2023-07-26 14:20 ` Alan Stern
2023-07-27 7:03 ` liulongfang
2023-07-27 8:47 ` Oliver Neukum
2023-07-27 14:42 ` Alan Stern
2023-07-27 15:31 ` Oliver Neukum [this message]
2023-07-27 15:57 ` Alan Stern
2023-08-10 1:20 ` liulongfang
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=e983fecd-ff59-e97e-0099-b33685d45d00@suse.com \
--to=oneukum@suse.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=liulongfang@huawei.com \
--cc=stern@rowland.harvard.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.