linux-kernel - Re: [PATCH] r8152: stop submitting rx for -EPROTO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 1 Oct 2021 11:22:26 -0400
From:   Alan Stern <stern@...land.harvard.edu>
To:     Hayes Wang <hayeswang@...ltek.com>
Cc:     Oliver Neukum <oneukum@...e.com>,
        Jason-ch Chen <jason-ch.chen@...iatek.com>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "Project_Global_Chrome_Upstream_Group@...iatek.com" 
        <Project_Global_Chrome_Upstream_Group@...iatek.com>,
        "hsinyi@...gle.com" <hsinyi@...gle.com>,
        nic_swsd <nic_swsd@...ltek.com>
Subject: Re: [PATCH] r8152: stop submitting rx for -EPROTO

On Fri, Oct 01, 2021 at 03:26:48AM +0000, Hayes Wang wrote:
> > Alan Stern <stern@...land.harvard.edu>
> > [...]
> > > There has been some discussion about this in the past.
> > >
> > > In general, -EPROTO is almost always a non-recoverable error.
> > 
> > Excuse me. I am confused about the above description.
> > I got -EPROTO before, when I debugged another issue.
> > However, the bulk transfer still worked after I resubmitted
> > the transfer. I didn't do anything to recover it. That is why
> > I do resubmission for -EPROTO.
> 
> I check the Linux driver and the xHCI spec.
> The driver gets -EPROTO for bulk transfer, when the host
> returns COMP_USB_TRANSACTION_ERROR.
> According to the spec of xHCI, USB TRANSACTION ERROR
> means the host did not receive a valid response from the
> device (Timeout, CRC, Bad PID, unexpected NYET, etc.).

That's right.  If the device and cable are working properly, this 
should never happen.  Or only extremely rarely (for example, caused 
by external electromagnetic interference).

> It seems to be reasonable why resubmission sometimes works.

Did you ever track down the reason why you got the -EPROTO error 
while debugging that other issue?  Can you reproduce it?

Alan Stern