linux-kernel - Re: [PATCH] usb: dwc3: gadget: Properly handle miss isoc event

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

Message-ID: <20230713154535.hsizn2e2fqenkslb@synopsys.com>
Date:   Thu, 13 Jul 2023 15:45:44 +0000
From:   Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To:     William Wu <william.wu@...k-chips.com>
CC:     Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "frank.wang@...k-chips.com" <frank.wang@...k-chips.com>,
        "jianwei.zheng@...k-chips.com" <jianwei.zheng@...k-chips.com>,
        "yangbin@...k-chips.com" <yangbin@...k-chips.com>
subject: Re: [PATCH] usb: dwc3: gadget: Properly handle miss isoc event

On Thu, Jul 13, 2023, William Wu wrote:
> If miss isoc event happens, the current code just set
> the req status to -EXDEV and giveback the req to the usb
> gadget driver, and then stop the active transfer with the
> cmd DWC3_DEPCMD_ENDTRANSFER and wait for a XferNotReady
> event to restart a transfer again. However, for isoc
> ep in transfer, it cause to lost the isoc data of the
> req.

That's intentional and expected behavior.

> 
> This patch moves the miss isoc req to pending_list in
> order to restart transfer immediately instead of give
> back the req to the usb gadget driver.

No. Now you're breaking the usage of isoc endpoint and also re-ordering
the transfer sequence.

> 
> Signed-off-by: William Wu <william.wu@...k-chips.com>

Regardless of direction, isoc data is time sensitive. If an isoc request
(or part of it) does not go out at a scheduled interval, then it's
dropped.

You should look into why it's being dropped (whether it's due to
software or hardware latency) and see if you can help it.

If your application does not care about the timing, then perhaps it
should use a different endpoint type.

If your application protocol requires the use of isoc endpoint and
somehow also demands no data drop tolerance, then you can workaround
that from the gadget driver. However I doubt this is the case.

BR,
Thinh