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

[Sasha Levin <sashal@kernel.org>]

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 :)

-- 
Thanks,
Sasha