On Mon, Feb 6, 2023 at 11:17 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Feb 06, 2023 at 11:33:15AM +0800, 朱忠杰 wrote: > > Yes, this is a very special case. > > > > It will happen only when disconnecting the mass storage if there are > > too many files in the storage, and the scanning operation is running, > > and the file system is not unmounted. > > It looks like this issue should be fixed in the usb mass storage > > driver, but I don't find an appropriate place. > > That's not surprising, because usb-storage doesn't know anything about > what's happening on the mass-storage device it connects to. All it does > is send the commands that it gets from the SCSI subsystem to the device > and receive the results back. It has no idea whether there is a mounted > filesystem on the device, if the filesystem contains any files, or > whether a scanning operation is running, > > A better place to look for fixing this might be the filesystem code. > That's where the information about mounting, files, and scanning can be > found. > > Alan Stern The problem is there is a for loop in the invalidate_inodes(), this function is in the block device driver. when the usb_disconnect is called, the filesystem is not umounted, userspace applications will be noticed the usb storage is disconnected, and then do the umounting work. the invalidate_inodes() is called in the usb hub worker, and will run for a long time. To fix this issue, the long running loop need to be moved out from the usb hub worker.
