linux-kernel - RE: [PATCH] usb:cdns3: Fix for CV CH9 running with g

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:   Tue, 8 Oct 2019 08:44:42 +0000
From:   Peter Chen <peter.chen@....com>
To:     Pawel Laszczak <pawell@...ence.com>
CC:     "felipe.balbi@...ux.intel.com" <felipe.balbi@...ux.intel.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "rogerq@...com" <rogerq@...com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jbergsagel@...com" <jbergsagel@...com>,
        "nsekhar@...com" <nsekhar@...com>, "nm@...com" <nm@...com>,
        Suresh Punnoose <sureshp@...ence.com>,
        Rahul Kumar <kurahul@...ence.com>
Subject: RE: [PATCH] usb:cdns3: Fix for CV CH9 running with g_zero driver.

 
> >> Endpoint can defer transition to Halted state if endpoint has pending
> >> requests.
> >
> >The implementation of halt handling is a little complicated, you may
> >consider return -EAGAIN for functional stall through usb_ep_set_halt
> >from function driver if the requests are pending, it doesn't need to
> >defer such kinds of functional stall.
> 
> Yes, I remember your suggestion regarding using EAGAIN, but f_mass_storage
> Driver simple check the status and try to stall endpoint again after 100 ms.
> 
> What if Command Verifier ask for endpoint status before this time, or if the transfer
> will not be finished on time ? Then the CV test may fail.
> 
> So solution from this patch should be more certain.
> 

Your description is reasonable, since I have not met this issue, I would like
to know more about it: 
It occurs at CV9 or MSC test? For CV9 test, it may not try to stall non-ep0.
Which test case was failed?

Peter

> >
> >Peter
> >> Patch add additional condition that allows to return correct endpoint
> >> status during Get Endpoint Status request even if the halting
> >> endpoint is in progress.
> >>
> >> Reported-by: Rahul Kumar <kurahul@...ence.com>
> >> Signed-off-by: Rahul Kumar <kurahul@...ence.com>
> >> Signed-off-by: Pawel Laszczak <pawell@...ence.com>
> >> Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
> >> ---
> >>  drivers/usb/cdns3/ep0.c | 10 ++++++++--
> >>  1 file changed, 8 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/usb/cdns3/ep0.c b/drivers/usb/cdns3/ep0.c index
> >> 44f652e8b5a2..10ae03430f34 100644
> >> --- a/drivers/usb/cdns3/ep0.c
> >> +++ b/drivers/usb/cdns3/ep0.c
> >> @@ -234,9 +234,11 @@ static int cdns3_req_ep0_set_address(struct
> >> cdns3_device *priv_dev,  static int cdns3_req_ep0_get_status(struct
> cdns3_device *priv_dev,
> >>  				    struct usb_ctrlrequest *ctrl)  {
> >> +	struct cdns3_endpoint *priv_ep;
> >>  	__le16 *response_pkt;
> >>  	u16 usb_status = 0;
> >>  	u32 recip;
> >> +	u8 index;
> >>
> >>  	recip = ctrl->bRequestType & USB_RECIP_MASK;
> >>
> >> @@ -262,9 +264,13 @@ static int cdns3_req_ep0_get_status(struct
> cdns3_device *priv_dev,
> >>  	case USB_RECIP_INTERFACE:
> >>  		return cdns3_ep0_delegate_req(priv_dev, ctrl);
> >>  	case USB_RECIP_ENDPOINT:
> >> -		/* check if endpoint is stalled */
> >> +		index = cdns3_ep_addr_to_index(ctrl->wIndex);
> >> +		priv_ep = priv_dev->eps[index];
> >> +
> >> +		/* check if endpoint is stalled or stall is pending */
> >>  		cdns3_select_ep(priv_dev, ctrl->wIndex);
> >> -		if (EP_STS_STALL(readl(&priv_dev->regs->ep_sts)))
> >> +		if (EP_STS_STALL(readl(&priv_dev->regs->ep_sts)) ||
> >> +		    (priv_ep->flags & EP_STALL_PENDING))
> >>  			usb_status =  BIT(USB_ENDPOINT_HALT);
> >>  		break;
> >>  	default:
> >> --
> >> 2.17.1
> >>
> >
> >--
> >
> >Thanks,
> >Peter Chen
> 
> Regards,
> Pawel