linux-kernel - Re: [PATCH] usb: port: add delay after usb_hub_set_port

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

Message-ID: <5639afb1-217e-47f3-906d-e2b7b87bbe7f@rowland.harvard.edu>
Date: Wed, 11 Feb 2026 11:07:57 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Xu Yang <xu.yang_2@....com>, m.grzeschik@...gutronix.de,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	imx@...ts.linux.dev, jun.li@....com
Subject: Re: [PATCH] usb: port: add delay after usb_hub_set_port_power()

On Wed, Feb 11, 2026 at 04:47:42PM +0100, Greg KH wrote:
> On Wed, Feb 11, 2026 at 10:04:32AM -0500, Alan Stern wrote:
> > On Wed, Feb 11, 2026 at 06:36:28PM +0800, Xu Yang wrote:
> > > When disable the root hub port, somehow the device is disconnected and
> > > re-connected again. This happens because usb_clear_port_feature() does not
> > > clear a truly happened port change. That says, in fact, port change event
> > > may happen after usb_clear_port_feature() is called. Then the subsequent
> > > port change event will have impact on usb device suspend routine.
> > 
> > This is not a very good description of the problem.  Here's a better 
> > one:
> > 
> > When a port is disabled, an attached device will be disconnected.  This 
> > causes a port-status-change event, which will race with hub autosuspend 
> > (if the disabled port was the only connected port on its hub), causing 
> > an immediate resume and a second autosuspend.  Both of these can be 
> > avoided by adding a short delay after the call to 
> > usb_hub_set_port_power().
> 
> What guarantees that a "short delay" will solve this?  And how long of a
> delay?  What guarantees that sleeping will not just reduce the race
> window?

There is no guarantee, but the probability is high.  The delay merely 
needs to be long enough for the hub driver's kernel thread to handle the 
port-status-change event.  For root hubs, this is interrupt-driven so it 
should happen pretty quickly (unless the thread is busy handling another 
device or root hub).  For external hubs, the delay won't be long enough.

And even if the delay doesn't work, we're no worse off than we are now 
-- you end up with an autosuspend-autoresume-autosuspend sequence in 
quick succession, where the first two aren't necessary but do no real 
harm.

Another way to avoid the problem would be to set the root hub's 
autosuspend delay to a few milliseconds.  But we set the delay to 0 in 
commit 596d789a211d ("USB: set hub's default autosuspend delay as 0") 
for what seemed to be good reasons.

Alan Stern