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

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

[Sasha Levin]

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. 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

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

[Amir Goldstein]

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
>

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

[Jan Kara]

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

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

[Sasha Levin]

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

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

[Jan Kara]

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