MIME-Version: 1.0
References: <20230203072819.3408-1-zhongjiezhu1@gmail.com> <Y90egBL6HSoEdz2P@rowland.harvard.edu>
 <CAJnoMhNYDXjfttiio+P7k6W1fDU3N=jbjmZe+ZRVON=bqm0yvw@mail.gmail.com>
 <Y+EaIRHZfLs49w9L@rowland.harvard.edu> <CAJnoMhO_AWU0ABoJN_EQZ9BpnpgxSeuv26PqOJ1feLh_CdJHsg@mail.gmail.com>
 <Y+HObaGgp3fwrL/7@rowland.harvard.edu>
In-Reply-To: <Y+HObaGgp3fwrL/7@rowland.harvard.edu>
From:   Zhongjie Zhu <zhongjiezhu1@gmail.com>
Date:   Tue, 7 Feb 2023 16:23:44 +0800
Message-ID: <CAJnoMhMDcvsB18PnFxRrnJA+VGWCBmJUjFGjWZToYXB36+Xmtw@mail.gmail.com>
Subject: Re: [PATCH] USB: core: hub: fix usb_hub worker blocking
 drain_all_pages() worker issue
To:     Alan Stern <stern@rowland.harvard.edu>
Cc:     linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Feb 7, 2023 at 12:07 PM Alan Stern <stern@rowland.harvard.edu> wrot=
e:
>
> 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, =E6=9C=B1=E5=BF=A0=E6=9D=B0=
 wrote:
> > > > Yes, this is a very special case.
> > > >
> > > > It will happen only when disconnecting the mass storage if there ar=
e
> > > > too many files in the storage, and the scanning operation is runnin=
g,
> > > > 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 abou=
t
> > > what's happening on the mass-storage device it connects to.  All it d=
oes
> > > is send the commands that it gets from the SCSI subsystem to the devi=
ce
> > > and receive the results back.  It has no idea whether there is a moun=
ted
> > > 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

Yes, invalidate_inodes() will free all the inodes related to the
supper_block, there are more
than 20 thousands inodes (some times more) need to be freed, the perf
record shows the
cpu is busy running the spin_lock and spin_unlock in the
invalidate_inodes(). The work in
this function is to free all the inodes with the super_block.
Maybe I need to find out why the spin_lock is running so much first.