linux-kernel - Re: [PATCH v9 5/5] usb: host: enable USB offload during system sleep

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: <CAOuDEK2c-F8dEyR894c5=OVYTJiLX6y1e1vd1RKoxusNa5PFig@mail.gmail.com>
Date: Fri, 7 Feb 2025 19:00:00 +0800
From: Guan-Yu Lin <guanyulin@...gle.com>
To: Michał Pecio <michal.pecio@...il.com>
Cc: Thinh.Nguyen@...opsys.com, gregkh@...uxfoundation.org, kekrby@...il.com, 
	lijiayi@...inos.cn, linux-kernel@...r.kernel.org, linux-sound@...r.kernel.org, 
	linux-usb@...r.kernel.org, mathias.nyman@...el.com, oneukum@...e.com, 
	perex@...ex.cz, quic_jjohnson@...cinc.com, ricardo@...liere.net, 
	stern@...land.harvard.edu, sumit.garg@...aro.org, tiwai@...e.com
Subject: Re: [PATCH v9 5/5] usb: host: enable USB offload during system sleep

On Thu, Feb 6, 2025 at 8:13 AM Michał Pecio <michal.pecio@...il.com> wrote:
>
> Hi,
>
> > - not flushing the endpoints of actively offloaded USB devices. Given
> >   that the USB devices is used by another entity, unilaterally flush
> >   the endpoint might lead to unexpected behavior on another entity.
>
> This doesn't seem right, because flushing applies to URBs managed by
> the kernel, so it should have no effect on offloaded endpoints.
>
> As far as I understand from your earlier discussion with Alan Stern,
> the real reason is that it disrupted operation of class drivers, in
> particular causing kernel-managed interrupt endpoints not to be polled
> during suspend and some events were being lost.
>
> Or maybe the real problem was that if the INT IN endpoint isn't being
> polled, device events don't trigger xHCI IRQs that wake up the CPU?
>

The main reason is as you described above. Without polling the INT IN
endpoint, some functions (e.g. hid, hub) failed during system suspend.

>
> And by the way, usb_hcd_flush_endpoint() doc states that no new URBs
> may be submitted during this call. I wonder if this can be guaranteed
> if the interface has not been suspended first? Perhaps this alone is
> good reason not to flush.
>
> Regards,
> Michal

To my understanding if the interface creates another URB, then the
interface might be able to submit it. Is there a reason to not
flushing all endpoints on a USB device when we have offloaded transfer
happening during system suspend? If there is, we'll identify what kinds
of endpoints are influenced and not flush them independently.
Otherwise, not flushing all of them might maintain a simpler code
logic.

Regards,
Guan-Yu