linux-kernel - Re: [PATCH] usb: hub: Resume hubs to find newly connected device

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]

Date:   Thu, 9 Dec 2021 11:04:13 -0500
From:   Alan Stern <stern@...land.harvard.edu>
To:     Kai-Heng Feng <kai.heng.feng@...onical.com>
Cc:     gregkh@...uxfoundation.org, mathias.nyman@...ux.intel.com,
        Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        Bixuan Cui <cuibixuan@...wei.com>,
        Andrew Lunn <andrew@...n.ch>,
        Chris Chiu <chris.chiu@...onical.com>,
        Rajat Jain <rajatja@...gle.com>, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: hub: Resume hubs to find newly connected device

On Thu, Dec 09, 2021 at 09:19:24AM +0800, Kai-Heng Feng wrote:
> On Thu, Dec 9, 2021 at 5:45 AM Alan Stern <stern@...land.harvard.edu> wrote:
> >
> > On Wed, Dec 08, 2021 at 03:08:33PM +0800, Kai-Heng Feng wrote:
> > > When a new USB device gets plugged to nested hubs, the affected hub,
> > > which connects to usb 2-1.4-port2, doesn't report there's any change,
> > > hence the nested hubs go back to runtime suspend like nothing happened:
> >
> > That's a bug in the hub.  When there's a change in the connection status
> > of one of its ports, it should report this change to the kernel.
> 
> I think it should, but when I searched through the USB spec and I
> can't find anywhere specify hub requires to report it in change
> status.

USB-2.0 spec, section 11.24.2.7.2.1 (C_PORT_CONNECTION):

	This bit is set when the PORT_CONNECTION bit changes because of an 
	attach or detach detect event (see Section 7.1.7.3). This bit will be 
	cleared to zero by a ClearPortFeature(C_PORT_CONNECTION) request or 
	while the port is in the Powered-off state.

> > So because of this buggy hub, you now want to wake up _every_ hub in the
> > system whenever any wakeup event occurs?  Is this really a good idea?
> > Is there a better way to solve the problem, such as a special quirk
> > flag?
> 
> If there's no other activities, the USB hub should go back to suspend
> immediately, so the impact is minimal.

Not immediately, but after a few seconds.  However your patch will affect every 
hub, not just the one that the new device was plugged into.

> I've seen several similar bug reports so I think this solution should
> be applied for all hubs.

Maybe those bug reports all had something in common, such as the type of hub or 
the bus speed they were running at.  Did you check?

Alan Stern