linux-kernel - Re: [PATCH] USB: core: hub: fix usb_hub worker blocking drain_all

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: <CAJnoMhO_AWU0ABoJN_EQZ9BpnpgxSeuv26PqOJ1feLh_CdJHsg@mail.gmail.com>
Date:   Tue, 7 Feb 2023 10:02:51 +0800
From:   Zhongjie Zhu <zhongjiezhu1@...il.com>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: core: hub: fix usb_hub worker blocking
 drain_all_pages() worker issue

On Mon, Feb 6, 2023 at 11:17 PM Alan Stern <stern@...land.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.