linux-kernel - Re: [PATCH v2] usbip: convert to use faux

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: <a735f877-e13b-498f-9eee-53ebefa8ebc9@rowland.harvard.edu>
Date: Thu, 10 Jul 2025 10:06:03 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Shuah Khan <skhan@...uxfoundation.org>
Cc: Greg KH <gregkh@...uxfoundation.org>, Zongmin Zhou <min_halo@....com>,
	shuah@...nel.org, valentina.manea.m@...il.com, i@...ithal.me,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
	zhouzongmin@...inos.cn
Subject: Re: [PATCH v2] usbip: convert to use faux_device

On Wed, Jul 09, 2025 at 03:57:35PM -0600, Shuah Khan wrote:
> On 7/9/25 15:49, Shuah Khan wrote:
> > Right. We have a few too many moving pieces here:
> > 
> > usbipd (user-space)
> > vhci_hcd and the usb devices it creates
> > 
> > usbip_host, stub driver that proxies between the device
> > on the server and vhci_client.
> > 
> > PM can be complex and it has to do lot more than it currently
> > does on both server and client end to support seamlessly.
> > 
> > The current suspend took the approach of refusing suspend
> > which doesn't work since usb devices underneath hang in
> > usb_dev_resume(). Looks like this usb device is treated like
> > a real device bu usb core. Is there a way to have usb core
> > PM (suspend and resume) handle them as virtual? Would it
> > help to use "supports_autosuspend" to disable suspend and
> > resume?
> 
> Would it work if usb_disable_autosuspend() on the devices
> that hang off its vitual bus?

You have to consider PM on both the host and client.  And you have to 
consider both runtime PM and system PM (that is, suspend to RAM, 
hibernate, etc.).

On the server, any sort of suspend will interrupt the connection.  
usb_disable_autosuspend() will prevent runtime suspends, but you 
shouldn't try to prevent system suspends.  Instead, the usbip driver on 
the server should have its suspend routine close the connection to the 
client (rather as if the server's user had unplugged the device).

On the client, you've got a choice for how to handle runtime PM.  You 
can leave it enabled, and when the client decides to suspend the device, 
tell the server's driver.  The server driver can then attempt to do a 
runtime suspend on the physical device.  (You might need to add a new 
type of message to the USBIP protocol to accomplish this; I don't know 
the details.)  Alternatively, you can forbid runtime suspend on the 
client entirely, although it would be nice if you could avoid this.

System PM on the client can be handled more less the same as runtime PM.

Alan Stern