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

[Sasha Levin <sashal@kernel.org>]

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