linux-kernel - Re: [PATCH] usb: xhci: lack of clearing xHC resources

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: <7ca4737a-aac6-4a14-8629-bd5404a6f902@rowland.harvard.edu>
Date: Mon, 17 Feb 2025 09:55:41 -0500
From: "stern@...land.harvard.edu" <stern@...land.harvard.edu>
To: Pawel Laszczak <pawell@...ence.com>
Cc: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"krzysztof.kozlowski@...aro.org" <krzysztof.kozlowski@...aro.org>,
	"christophe.jaillet@...adoo.fr" <christophe.jaillet@...adoo.fr>,
	"javier.carrasco@...fvision.net" <javier.carrasco@...fvision.net>,
	"make_ruc2021@....com" <make_ruc2021@....com>,
	"peter.chen@....com" <peter.chen@....com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Pawel Eichler <peichler@...ence.com>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] usb: xhci: lack of clearing xHC resources

On Mon, Feb 17, 2025 at 06:25:35AM +0000, Pawel Laszczak wrote:
> >> For this scenario during enumeration of USB LS/FS device the Cadence xHC
> >reports completion error code for xHCi commands because the devices was
> >not property disconnected and in result the xHC resources has not been
> >correct freed.
> >> XHCI specification doesn't mention that device can be reset in any order so,
> >we should not treat this issue as Cadence xHC controller bug.
> >> Similar as during disconnecting in this case the device should be cleared
> >starting form the last usb device in tree toward the root hub.
> >> To fix this issue usbcore driver should disconnect all USB devices connected
> >to hub which was reconnected while suspending.
> >
> >No, that's not right at all.  We do not want to disconnect these devices if
> >there's any way to avoid it.
> >
> >There must be another way to tell the host controller to release the devices'
> >resources.  Doesn't the usb_reset_and_verify_device() call do something like
> >that anyway?  After all, the situation should be very similar to what happens
> >when a device is simply reset.
> >
> >Alan Stern
> 
> 
> Yes, I had such idea too, but the current solution is simpler.
> I don't understand why in this case we can't do disconnect
> The hub connected to host was physically disconnected during suspend, so 
> It seems quite logic to make disconnection. 
> Can you comment why we should not make disconnection?

Imagine that there is a disk drive plugged into the hub, and the drive 
is mounted with various files open or being written when the system gets 
suspended.  While the system is asleep, the user unplugs the hub but 
then plugs it back in before the system resumes.

Under those circumstances, the user expects that the drive will remain 
mounted, the files will remain open, and there won't be any data 
corruption on the drive when the system starts running again.  But if we 
said that all the devices below the hub were disconnected then none of 
those things would happen and the user would lose data.

Note that the same sort of thing can happen on some systems even if the 
hub does not get unplugged, because these systems do not provide suspend 
power to their USB controllers.  In addition, the same sort of thing 
happens every time a system goes into S4 hibernation.  You wouldn't want 
to force all users to unmount their USB drives whenever they hibernate 
their systems, would you?

This is why we should avoid saying that devices were disconnected during 
suspend.

Alan Stern