The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: liulongfang <liulongfang@huawei.com>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] USB:bugfix a controller halt error
Date: Wed, 26 Jul 2023 09:18:15 +0200	[thread overview]
Message-ID: <2023072629-unblended-perky-4732@gregkh> (raw)
In-Reply-To: <bc2cd818-c7ad-9061-29ce-f5390d44d8ab@huawei.com>

On Wed, Jul 26, 2023 at 02:44:01PM +0800, liulongfang wrote:
> On 2023/7/21 19:08, Greg KH Wrote:
> > On Fri, Jul 21, 2023 at 06:00:15PM +0800, liulongfang wrote:
> >> On systems that use ECC memory. The ECC error of the memory will
> >> cause the USB controller to halt. It causes the usb_control_msg()
> >> operation to fail.
> > 
> > Why does ECC memory matter here?
> >
> 
> This is a test conducted under a special test scenario.
> ECC memory errors are caused by some test tools.

What memory is failing, and why does just this single check matter in
the whole kernel?

If hardware is broken, and failing, it's not the job of the kernel to
protect against that, is it?  Shouldn't the ECC memory controller have
properly notified the kernel of the fault and reset the machine because
it is now in an undetermined state?

> > Are you sure this is correct?  How was this tested?  Seems to me that
> > this will still return "success" if this code path ever happens, what am
> 
> You are right. I made a patch error here. The code modification should be like this:
> if (r < 0) {
> 	retval = r;
> 	kfree(buf);
> 	goto fail;
> }

This means that you didn't test this change at all, so I don't really
think it is needed :(

thanks,

greg k-h

  reply	other threads:[~2023-07-26  7:22 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 [this message]
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
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=2023072629-unblended-perky-4732@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=liulongfang@huawei.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