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

Amir Goldstein
2026-02-15T08:11:43Z

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.

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/

I don't expect major backport issues to kernel >= 6.10 with commit
07a3b8d0bf726 ("fsnotify: lazy attach fsnotify_sb_info state to sb")

Backporting below 6.10 will require more dependencies.

Thanks,
Amir.

> So move shutdown of fsnotify subsystem
> before shrinking of dcache.
>
> Link: https://lore.kernel.org/linux-fsdevel/CAOQ4uxgXvwumYvJm3cLDFfx-TsU3g5-yVsTiG=6i8KS48dn0mQ@mail.gmail.com/
> Reported-by: Jakub Acs <acsjakub@amazon.de>
> Reviewed-by: Amir Goldstein <amir73il@gmail.com>
> Reviewed-by: Christian Brauner <brauner@kernel.org>
> Signed-off-by: Jan Kara <jack@suse.cz>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>
> LLM Generated explanations, may be completely bogus:
>
> The function is present and the code structure in the current tree
> matches what we see in the diff. This function has been in
> `generic_shutdown_super()` for a long time and would exist in all active
> stable trees.
>
> ### 8. SUMMARY
>
> | Criteria | Assessment |
> |----------|-----------|
> | Fixes real bug | YES — NULL deref / crash during unmount |
> | Obviously correct | YES — simple reorder, reviewed by 2 top
> maintainers |
> | Small and contained | YES — 1 file, ~6 lines, moving 1 function call |
> | No new features | Correct — pure bug fix |
> | Risk of regression | Very low — only slight performance impact |
> | User impact | HIGH — affects any system with fsnotify watches during
> unmount |
> | Reported by real user | YES (Jakub Acs) |
>
> This is an excellent stable candidate: a small, well-reviewed fix for a
> real crash that affects common operations (filesystem unmount with
> inotify/fanotify watches). The fix is trivial to understand (reorder one
> function call), reviewed by the subsystem and VFS maintainers, and
> carries essentially no risk of regression.
>
> **YES**
>
> fs/super.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/super.c b/fs/super.c
> index 3d85265d14001..9c13e68277dd6 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -618,6 +618,7 @@ void generic_shutdown_super(struct super_block *sb)
> const struct super_operations *sop = sb->s_op;
>
> if (sb->s_root) {
> + fsnotify_sb_delete(sb);
> shrink_dcache_for_umount(sb);
> sync_filesystem(sb);
> sb->s_flags &= ~SB_ACTIVE;
> @@ -629,9 +630,8 @@ void generic_shutdown_super(struct super_block *sb)
>
> /*
> * Clean up and evict any inodes that still have references due
> - * to fsnotify or the security policy.
> + * to the security policy.
> */
> - fsnotify_sb_delete(sb);
> security_sb_delete(sb);
>
> if (sb->s_dio_done_wq) {
> --
> 2.51.0
>