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

Jan Kara
2026-02-26T15:57:57Z

On Thu 26-02-26 09:09:13, Sasha Levin wrote:
> On Tue, Feb 17, 2026 at 11:00:42AM +0100, Jan Kara wrote:
> > 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.
>
> Looks like going even to 6.18 requires a bunch of dependencies, so a backport
> would be appreciated :)

Well, given nobody hit the race in practice (not even syzbot) and I don't
know of a way to even theoretically trigger this without CAP_SYS_ADMIN, I
don't think significant effort in fixing this is really warranted...

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