linux-kernel - Re: [PATCH next] usb: usbfs: Add reset

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: <45b87923-d256-4c5e-8167-8ef764add1e9@kylinos.cn>
Date: Wed, 17 Jul 2024 11:13:39 +0800
From: Hongyu Xie <xy521521@...il.com>
To: stern@...land.harvard.edu,
	xy521521@...il.com,
	oneukum@...e.com
Cc: gregkh@...uxfoundation.org,
	brauner@...nel.org,
	jlayton@...nel.org,
	jack@...e.cz,
	linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	xiehongyu1@...inos.cn
Subject: Re: [PATCH next] usb: usbfs: Add reset_resume for usbfs

From: Hongyu Xie <xiehongyu1@...inos.cn>



On 2024/7/17 10:05, Alan Stern wrote:
> I'm ignoring most of what you asked Oliver to focus on just one thing:
> 
> On Wed, Jul 17, 2024 at 09:43:38AM +0800, Hongyu Xie wrote:
>> Even before usbfs->reset_resume is called (if there is one), the USB device
>> has already been reset and in a good state.
> 
> You are wrong to think that being reset means the device is in a good
> state.
> 
> The userspace driver may have very carefully put the device into some
> non-default state with special settings.  All those settings will be
> lost when the device gets reset, and they will have to be reloaded
> before the device can function properly.  But the userspace driver won't
> even know this has happened unless the kernel tells it somehow.
> 
I was looking the whole thing from kernel's perspective. Thank you for 
pointing it out for me.
> Oliver is pointing out that the kernel has to tell the userspace driver
> that all the settings have been lost, so the driver will know it needs
> to load them back into the device.  Currently we have no way to send
> this information to the driver.  That's why usbfs doesn't have a
> reset_resume callback now.
But I still think that there's no need to rebind for a USB device that 
was using usbfs. Because rebinding doesn't fix settings lost. And it 
looks strange from user-space's perspective.
What do you think?
> 
> Alan Stern