linux-kernel - Re: [PATCHv2] musb_host: fix lockup on rxcsr_h

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 5 May 2016 08:31:13 -0500
From:	Bin Liu <b-liu@...com>
To:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
CC:	Yegor Yefremov <yegorslists@...glemail.com>,
	Maxim Uvarov <muvarov@...il.com>,
	kernel list <linux-kernel@...r.kernel.org>,
	linux-usb <linux-usb@...r.kernel.org>,
	Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

Hi,

On Thu, May 05, 2016 at 04:21:23PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 5/4/2016 10:17 PM, Bin Liu wrote:
> 
> >>>>>>>>>>yes, it also works with that reset and go to finish:
> >>>>>>>>>>
> >>>>>>>>>>diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> >>>>>>>>>>index c3d5fc9..8cd98e7 100644
> >>>>>>>>>>--- a/drivers/usb/musb/musb_host.c
> >>>>>>>>>>+++ b/drivers/usb/musb/musb_host.c
> >>>>>>>>>>@@ -1599,6 +1599,10 @@ void musb_host_rx(struct musb *musb, u8 epnum)
> >>>>>>>>>>                status = -EPROTO;
> >>>>>>>>>>                musb_writeb(epio, MUSB_RXINTERVAL, 0);
> >>>>>>>>>>
> >>>>>>>>>>+               rx_csr &= ~MUSB_RXCSR_H_ERROR;
> >>>>>>>>>>+               musb_writew(epio, MUSB_RXCSR, rx_csr);
> >>>>>>>>>>+
> >>>>>>>>>>+               goto finish;
> >>>>>>>>>>        } else if (rx_csr & MUSB_RXCSR_DATAERROR) {
> >>>>>>>>>>
> >>>>>>>>>>                if (USB_ENDPOINT_XFER_ISOC != qh->type) {
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>Thanks for testing it.
> >>>>>>>>
> >>>>>>>>Have tested your patch and now both FT4232 and Huawei don't freeze on removal.
> >>>>>>>>
> >>>>>>>>Bin, Max thanks for fixing this issue.
> >>>>>>>>
> >>>>>>>>Tested-by: Yegor Yefremov <yegorslists@...glemail.com>
> >>>>>>>
> >>>>>>>Thanks for testing.
> >>>>>>>
> >>>>>>>Can you please test the patch [1] instead? I'd like to use it as the
> >>>>>>>fix.
> >>>>>>>
> >>>>>>>[1] http://marc.info/?l=linux-usb&m=146222355213935&w=2
> >>>>>>
> >>>>>>The patch behaves the same as the previous one.
> >>>>>>
> >>>>>>Kernel: 4.6-rc6
> >>>>>
> >>>>>Thanks for testing. I will add your Tested-by.
> >>>>
> >>>>If you'll resend this patch, it would be good to add it to stable
> >>>>kernels. I've tested 3.18.32 and it fixes the error too.
> >>
> >>>Thanks for testing.
> >>>
> >>>My plan is to not rush it into stable, but let it sit in v4.7 for a
> >>>while first.
> >>
> >>   Are you serious? Fixing interrupt storm due to not cleared
> >>interrupt bit will only be done in 4.7?
> >
> >Well, I am new to maintianer's role, and thought there is only one week
> >away to v4.7 merge window, there is no big difference to let this patch
> >get into v4.7-rc1. If getting the fix into upstream as soon as possible
> >is important, I will send it for 4.6-rc7.
> >
> >BTY, the issue is not because of not clearing interrupt bit, but the hub
> >has no chance to report the disconnect event, which causes the
> >controller keeps generating the interrupt for every new rx urb.
> 
>    Sorry, looking at the Mentor manuals, I got the impression that
> whenever the RXCSR.Error is set, there's interrupt. Probably they

This is my understanding of the manual too.

> meant that the interrupt is generated only on transition from 0 to
> 1....

What transition? the RXCSR bit? 'set' means from 0 to 1, 'clear' means 1
-> 0, right? I don't see you have any misunderstanding.

> 
> >Regards,
> >-Bin.
> 
> MBR, Sergei
>