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: <dd3659dd-7e45-479d-ab65-9f5c1bab26a0@rowland.harvard.edu>
Date: Wed, 9 Jul 2025 10:20:15 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Zongmin Zhou <min_halo@....com>, Shuah Khan <skhan@...uxfoundation.org>,
	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 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.

Alan Stern