Re: [PATCH AUTOSEL 6.19-5.15] fsnotify: Shutdown fsnotify before destroying sb's dcache

Jan Kara
2026-02-17T10:00:59Z

On Sun 15-02-26 09:11:30, Amir Goldstein wrote:
> On Sat, Feb 14, 2026 at 11:27 PM Sasha Levin <sashal@kernel.org> wrote:
> >
> > From: Jan Kara <jack@suse.cz>
> >
> > [ Upstream commit 74bd284537b3447c651588101c32a203e4fe1a32 ]
> >
> > Currently fsnotify_sb_delete() was called after we have evicted
> > superblock's dcache and inode cache. This was done mainly so that we
> > iterate as few inodes as possible when removing inode marks. However, as
> > Jakub reported, this is problematic because for some filesystems
> > encoding of file handles uses sb->s_root which gets cleared as part of
> > dcache eviction. And either delayed fsnotify events or reading fdinfo
> > for fsnotify group with marks on fs being unmounted may trigger encoding
> > of file handles during unmount.
>
> In retrospect, the text "Now that we iterate inode connectors..."
> would have helped LLM (as well as human) patch backports understand
> that this is NOT a standalone patch.

Good point :)

> Sasha,
>
> I am very for backporting this fix, but need to backport the series
> https://lore.kernel.org/linux-fsdevel/20260121135513.12008-1-jack@suse.cz/

Yes. Without commits 94bd01253c3d5 ("fsnotify: Track inode connectors for a
superblock") and a05fc7edd988c ("fsnotify: Use connector list for
destroying inode marks") the reordering alone can cause large latencies
during filesystem unmount.

Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR