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: <ce96291b-c0b2-41cf-a71c-c13bd8d0f139@linuxfoundation.org>
Date: Wed, 9 Jul 2025 15:49:57 -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 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?

This would solve the hang during usb_dev_resume() problem.

Maybe vhci_hcd isn't a good candidate for faux bus? It appears
we might have a need for a shutdown, suspend at the very least
to be able to support reboot/suspend/resume cases?

The current code doesn't handle suspend/resume correctly when
devices are imported.

thanks,
-- Shuah