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]
Message-ID: <BL0PR02MB56338A2EA4515527AA0EECF5A7A50@BL0PR02MB5633.namprd02.prod.outlook.com>
Date:   Mon, 10 Dec 2018 08:56:43 +0000
From:   Anurag Kumar Vulisha <anuragku@...inx.com>
To:     Felipe Balbi <balbi@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Shuah Khan <shuah@...nel.org>,
        Alan Stern <stern@...land.harvard.edu>,
        Johan Hovold <johan@...nel.org>,
        Jaejoong Kim <climbbb.kim@...il.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Roger Quadros <rogerq@...com>,
        Manu Gautam <mgautam@...eaurora.org>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        Bart Van Assche <bvanassche@....org>,
        Mike Christie <mchristi@...hat.com>,
        Matthew Wilcox <willy@...radead.org>,
        Colin Ian King <colin.king@...onical.com>
CC:     "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "v.anuragkumar@...il.com" <v.anuragkumar@...il.com>,
        Thinh Nguyen <thinhn@...opsys.com>,
        Tejas Joglekar <tejas.joglekar@...opsys.com>,
        Ajay Yugalkishore Pandey <APANDEY@...inx.com>
Subject: RE: [PATCH v7 09/10] usb: dwc3: Check for IOC/LST bit in both
 event->status and TRB->ctrl fields

Hi Felipe,

>-----Original Message-----
>From: Felipe Balbi [mailto:balbi@...nel.org]
>Sent: Monday, December 10, 2018 12:24 PM
>To: Anurag Kumar Vulisha <anuragku@...inx.com>; Greg Kroah-Hartman
><gregkh@...uxfoundation.org>; Shuah Khan <shuah@...nel.org>; Alan Stern
><stern@...land.harvard.edu>; Johan Hovold <johan@...nel.org>; Jaejoong Kim
><climbbb.kim@...il.com>; Benjamin Herrenschmidt <benh@...nel.crashing.org>;
>Roger Quadros <rogerq@...com>; Manu Gautam <mgautam@...eaurora.org>;
>martin.petersen@...cle.com; Bart Van Assche <bvanassche@....org>; Mike
>Christie <mchristi@...hat.com>; Matthew Wilcox <willy@...radead.org>; Colin Ian
>King <colin.king@...onical.com>
>Cc: linux-usb@...r.kernel.org; linux-kernel@...r.kernel.org;
>v.anuragkumar@...il.com; Thinh Nguyen <thinhn@...opsys.com>; Tejas Joglekar
><tejas.joglekar@...opsys.com>; Ajay Yugalkishore Pandey <APANDEY@...inx.com>
>Subject: RE: [PATCH v7 09/10] usb: dwc3: Check for IOC/LST bit in both event->status
>and TRB->ctrl fields
>
>
>Hi,
>
>Anurag Kumar Vulisha <anuragku@...inx.com> writes:
>> HI Felipe,
>>
>>>-----Original Message-----
>>>From: Felipe Balbi [mailto:balbi@...nel.org]
>>>Sent: Friday, December 07, 2018 11:42 AM
>>>To: Anurag Kumar Vulisha <anuragku@...inx.com>; Greg Kroah-Hartman
>>><gregkh@...uxfoundation.org>; Shuah Khan <shuah@...nel.org>; Alan Stern
>>><stern@...land.harvard.edu>; Johan Hovold <johan@...nel.org>; Jaejoong Kim
>>><climbbb.kim@...il.com>; Benjamin Herrenschmidt <benh@...nel.crashing.org>;
>>>Roger Quadros <rogerq@...com>; Manu Gautam <mgautam@...eaurora.org>;
>>>martin.petersen@...cle.com; Bart Van Assche <bvanassche@....org>; Mike
>>>Christie <mchristi@...hat.com>; Matthew Wilcox <willy@...radead.org>; Colin
>Ian
>>>King <colin.king@...onical.com>
>>>Cc: linux-usb@...r.kernel.org; linux-kernel@...r.kernel.org;
>>>v.anuragkumar@...il.com; Thinh Nguyen <thinhn@...opsys.com>; Tejas
>Joglekar
>>><tejas.joglekar@...opsys.com>; Ajay Yugalkishore Pandey
><APANDEY@...inx.com>
>>>Subject: RE: [PATCH v7 09/10] usb: dwc3: Check for IOC/LST bit in both event-
>>status
>>>and TRB->ctrl fields
>>>
>>>
>>>Hi,
>>>
>>>Anurag Kumar Vulisha <anuragku@...inx.com> writes:
>>>>>> @@ -2286,7 +2286,12 @@ static int
>>>>>dwc3_gadget_ep_reclaim_completed_trb(struct dwc3_ep *dep,
>>>>>>  	if (event->status & DEPEVT_STATUS_SHORT && !chain)
>>>>>>  		return 1;
>>>>>>
>>>>>> -	if (event->status & (DEPEVT_STATUS_IOC | DEPEVT_STATUS_LST))
>>>>>> +	if ((event->status & DEPEVT_STATUS_IOC) &&
>>>>>> +	    (trb->ctrl & DWC3_TRB_CTRL_IOC))
>>>>>> +		return 1;
>>>>>
>>>>>this shouldn't be necessary. According to databook, event->status
>>>>>contains the bits from the completed TRB.  Which means that
>>>>>event->status & IOC will always be equal to trb->ctrl & IOC.
>>>>>
>>>> Thanks for reviewing this patch. Lets consider an example where a
>>>> request has num_sgs > 0 and each sg is mapped to a TRB and the last
>>>> TRB has the IOC bit set. Once the controller is done with the
>>>> transfer, it  generates XferInProgress for the last TRB (since IOC bit
>>>> is set). As a part of trb reclaim process
>>>> dwc3_gadget_ep_reclaim_trb_sg() calls
>>>> dwc3_gadget_ep_reclaim_completed_trb() for req->num_sgs times. Since
>>>> the event already has the IOC bit set, the loop is exited from the
>>>> loop at the very first TRB and the remaining TRBs (mapped to the sglist) are left
>>>unhandled.
>>>> To avoid this we modified the code to exit only if both TRB & event
>>>> has the IOC bit set.
>>>
>>>Seems like IOC case should just test for chain flag as well:
>>>
>>
>> Okay. Along with this logic the code for updating chain bit should also be modified I
>guess.
>
>not really
>
>> Since the IOC bit is also set when there are not enough TRBs available, the code
>should be
>> modified to not set DWC3_TRB_CTRL_CHN bit when the IOC bit is set. I will update
>below
>> changes along with your suggestions and resend the patches.
>
>no. Actually I don't think we're allowed to split a scatter/gather like
>that. I did that quite a while ago, but I don't think we're allowed to
>do so. What we should do, in that case, is not even queue that request
>until we have enough for all members of the scatter/gather. But that's a
>separate patch, anyway.
>

Okay. I have a doubt here, not pushing the request until all sgs are mapped to enough TRBs
might remove the driver complexity but reduce the performance (since we are waiting
until enough TRBs are available). Are we okay with that?  

Thanks,
Anurag Kumar Vulisha  

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ