linux-kernel - Re:Re: [PATCH] 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: <4cdaecd1.131d.198dedeefe2.Coremail.ccc194101@163.com>
Date: Mon, 25 Aug 2025 09:36:49 +0800 (CST)
From: 自己 <ccc194101@....com>
To: "Alan Stern" <stern@...land.harvard.edu>, gregkh@...uxfoundation.org
Cc: jannh@...gle.com, rex.nie@...uarmicro.com, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	chenchangcheng <chenchangcheng@...inos.cn>
Subject: Re:Re: [PATCH] usb: usbfs: Add reset_resume callback to usbfs.

At 2025-08-23 04:30:18, "Alan Stern" <stern@...land.harvard.edu> wrote:
>On Fri, Aug 22, 2025 at 10:46:02AM +0800, ccc194101@....com wrote:
>> From: chenchangcheng <chenchangcheng@...inos.cn>
>> 
>> When an Apple device is inserted into the host, and the host
>> wakes up from S3/S4 power states, if the reset_resume process
>> is triggered, the absence of a reset_resume callback in usbfs will
>> cause the device to unbind.
>> By adding a reset_resume callback to usbfs and reporting REMOVE and ADD
>> uevents in reset_resume, the userspace is prompted to reissue commands
>> to re-establish the binding with usbfs.
>
>usbfs has no way to inform userspace when the device is reset.  This is 
>true for normal resets as well as for reset-resumes (no pre_reset, 
>post_reset, or reset_resume callbacks).  I don't see any point in trying 
>to add support for the latter but not the former.
>
>Unbinding the device forces userspace to re-open the device file and 
>establish a new binding.  How does adding REMOVE and ADD uevents make 
>the situation any better than it already is?
>

>Alan Stern

Here is my reasoning: 
Currently, for Apple devices after S3/S4 states, since the USB hub loses power, 
the reset-resume process is triggered during resume. If the original 
reset_resume process is followed, the device would be forcibly unbound,
and the device_attach function would be used to rebind the driver.
However, usbfs is different in that it cannot automatically rebind
after unbinding and requires a userspace ioctl to re-establish the binding.

If we assume that the reset_resume callback of usbfs does nothing
and simply returns 0, the USB device would still be reset. When userspace
uses the previous file descriptor handle to issue a command, it would result
in an error: "PTP_OC 0x1007 receiving resp failed: PTP Session Not Open (0x2003)."

Therefore, by adding REMOVE and ADD uevents in the reset_resume process,
userspace is notified to first unbind and then rebind. This approach avoids the aforementioned issue.

Chen Changcheng