lkml.org 
[lkml]   [2023]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] USB: core: hub: fix usb_hub worker blocking drain_all_pages() worker issue
On Tue, Feb 07, 2023 at 10:02:51AM +0800, Zhongjie Zhu wrote:
> On Mon, Feb 6, 2023 at 11:17 PM Alan Stern <stern@rowland.harvard.edu> 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.

Oh, maybe I didn't understand.

You've got a USB mass-storage device with a mounted filesystem and a lot
of dirty inodes, right? Then a USB disconnect happens, and as part of
the disconnect processing, invalidate_inodes() runs for a long time.

Do you know why it takes so long? The I/O operations shouldn't need any
time; they will all fail immediately because the device has been
disconnected and so there is no way to communicate with it.

Alan Stern

\
 
 \ /
  Last update: 2023-03-27 00:12    [W:2.102 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site