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: <4478924b-fbd7-4a5a-ad0d-4fe0569b4971@linuxfoundation.org>
Date: Wed, 9 Jul 2025 15:57:35 -0600
From: Shuah Khan <skhan@...uxfoundation.org>
To: Alan Stern <stern@...land.harvard.edu>,
 Greg KH <gregkh@...uxfoundation.org>
Cc: 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,
 Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH v2] usbip: convert to use faux_device

On 7/9/25 15:49, Shuah Khan wrote:
> On 7/9/25 08:20, Alan Stern wrote:
>> On Wed, Jul 09, 2025 at 12:06:57PM +0200, Greg KH wrote:
>>> On Wed, Jul 09, 2025 at 05:07:24PM +0800, Zongmin Zhou wrote:
>>>>>> In fact, I've experimented with adding PM hooks to the faux bus,
>>>>>> and found that faux bus devices then behave identically to platform
>>>>>> bus devices during suspend/resume.
>>>>>> See the attachment.
>>>>>>
>>>>>
>>>>> Thanks for checking this scenario. No surprises here.
>>>> Another part of my purpose in doing this is that the vhci-hcd driver seems
>>>> should still retain suspend/resume hooks. Therefore, the faux bus should
>>>> add corresponding hooks to allow the driver to call its own pm functions.
>>>> Though currently don't know how to fix this problem yet.
>>>
>>> I have no problem with adding the pm functions to the faux bus, BUT it
>>> needs to make sense as to why they would be needed at all as this is not
>>> a "real" device or bus that should need to do anything when
>>> suspend/resume happens.
>>
>> The unique problem faced by vhci-hcd is that the devices it controls
>> reside on external computer systems that have a lot of their own state,
>> much more than ordinay USB devices have.  Consequently vhci-hcd may need
>> to do more work for a PM transition than a normal driver would.
>>
>> As an analogy, suppose you're running a program that has an open TCP
>> connection to an external server.  If you suspend your computer, it
>> won't be able to send the TCP keepalive packets that the server expects,
>> and the server will eventually close the connection.  Then when your
>> computer resumes, your program may misbehave when it finds its
>> connection has spontaneously been closed for no apparent reason.
>>
> 
> 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?

thanks,
-- Shuah