linux-kernel - Re: [PATCH v1 1/2] usb: dwc3: Not set DWC3_EP_END_TRANSFER

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] [day] [month] [year] [list]

Date:   Tue, 15 Feb 2022 15:08:36 +0900
From:   Jung Daehwan <dh10.jung@...sung.com>
To:     Wesley Cheng <quic_wcheng@...cinc.com>
Cc:     Felipe Balbi <balbi@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org,
        open list <linux-kernel@...r.kernel.org>,
        quic_jackp@...cinc.com, Thinh.Nguyen@...opsys.com
Subject: Re: [PATCH v1 1/2] usb: dwc3: Not set DWC3_EP_END_TRANSFER_PENDING
 in ep cmd fails

On Mon, Feb 14, 2022 at 10:53:14AM -0800, Wesley Cheng wrote:
> Hi Daehwan,
> 
> On 2/14/2022 1:37 AM, Daehwan Jung wrote:
> > It always sets DWC3_EP_END_TRANSFER_PENDING in dwc3_stop_active_transfer
> > even if dwc3_send_gadget_ep_cmd fails. It can cause some problems like
> > skipping clear stall commmand or giveback from dequeue. We fix to set it
> > only when ep cmd success. Additionally, We clear DWC3_EP_TRANSFER_STARTED
> > for next trb to start transfer not update transfer.
> > 
> > Change-Id: I2e6b58acc99f385e467e8b639a3792a5e5f4d2bb
> > Signed-off-by: Daehwan Jung <dh10.jung@...sung.com>
> > ---
> >  drivers/usb/dwc3/gadget.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> > index 183b90923f51..3ad3bc5813ca 100644
> > --- a/drivers/usb/dwc3/gadget.c
> > +++ b/drivers/usb/dwc3/gadget.c
> > @@ -2044,6 +2044,12 @@ static int dwc3_gadget_ep_dequeue(struct usb_ep *ep,
> >  				dwc3_gadget_move_cancelled_request(r,
> >  						DWC3_REQUEST_STATUS_DEQUEUED);
> >  
> > +			/* If ep cmd fails, then force to giveback cancelled requests here */
> > +			if (!(dep->flags & DWC3_EP_END_TRANSFER_PENDING)) {
> > +				dep->flags &= ~DWC3_EP_TRANSFER_STARTED;
> > +				dwc3_gadget_ep_cleanup_cancelled_requests(dep);
> > +			}
> > +
> What I realized when looking at the endxfer command fail due to TIMEOUT,
> was that it would lead to subsequent controller halt failures as well
> (during pullup disable case).  It might not be safe to forcefully unmap
> the request buffers if the controller may still be "working" on it.
>
Hi Wesley,

I agree with your opinion that the controller may still be "working" on
it.

> I found some interesting quirks with regards to endxfer timeouts as
> well, which I'm trying to get some more feedback on [1].  What is the
> end issue being seen that requires this change? (we may have run into
> the same issue as well.
> 
> [1] -
> https://protect2.fireeye.com/v1/url?k=9d423b69-fc3fd32e-9d43b026-74fe485fff30-77a099b52659410d&q=1&e=20b4d9f5-2599-4f57-8b6a-7c4ec167d228&u=https%3A%2F%2Flore.kernel.org%2Flinux-usb%2F20220203080017.27339-1-quic_wcheng%40quicinc.com%2F

I had adb hung issue if ep cmd timeout occurs. I also think we may have
run into the same issue. I'm going to see your patches.
Thanks for your comment.

Best Regards,
Jung Daehwan

> 
> Thanks
> Wesley Cheng
> >  			dep->flags &= ~DWC3_EP_WAIT_TRANSFER_COMPLETE;
> >  
> >  			goto out;
> > @@ -3645,7 +3651,7 @@ static void dwc3_stop_active_transfer(struct dwc3_ep *dep, bool force,
> >  
> >  	if (!interrupt)
> >  		dep->flags &= ~DWC3_EP_TRANSFER_STARTED;
> > -	else
> > +	else if (!ret)
> >  		dep->flags |= DWC3_EP_END_TRANSFER_PENDING;
> >  }
> >  
>