linux-kernel - Re: [RESEND PATCH v3 2/2] usb: dwc3: Wait for control tranfer completed when stopping gadget

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: <CAMz4kuLQK8bkjGqjuUVTh6ZrMXk=xB7B0Ka=TRj4BD8iSG4ZDw@mail.gmail.com>
Date:   Thu, 13 Oct 2016 15:51:44 +0800
From:   Baolin Wang <baolin.wang@...aro.org>
To:     Felipe Balbi <balbi@...nel.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Mark Brown <broonie@...nel.org>,
        USB <linux-usb@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH v3 2/2] usb: dwc3: Wait for control tranfer
 completed when stopping gadget

Hi,

On 13 October 2016 at 15:08, Felipe Balbi <balbi@...nel.org> wrote:
>
> Hi,
>
> Baolin Wang <baolin.wang@...aro.org> writes:
>> @@ -1487,10 +1496,22 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int is_on)
>>
>>       is_on = !!is_on;
>>
>> +try_again:
>>       spin_lock_irqsave(&dwc->lock, flags);
>>       ret = dwc3_gadget_run_stop(dwc, is_on, false);
>>       spin_unlock_irqrestore(&dwc->lock, flags);
>>
>> +     if (ret == -EBUSY) {
>> +             ret = wait_for_completion_timeout(&dwc->ep0_in_setup,
>> +                                               msecs_to_jiffies(500));
>> +             if (ret == 0) {
>> +                     dev_err(dwc->dev, "timeout to stop gadget.\n");
>> +                     ret = -ETIMEDOUT;
>> +             } else {
>> +                     goto try_again;
>
> you are not really reading my comments. It's the third time I tell you
> there's no need for try_again. If you can't complete a control transfer
> in 500ms, you already have other issues. Take this thing out of here.

I think you misunderstood the code. If there is 500ms timeout, we will
return '-ETIMEDOUT' error. If the control transfer is completed before
timeout, we can not just return and we need try again to stop the
gadget, right? Any other good suggestion? Thanks.


-- 
Baolin.wang
Best Regards