Linux: Fix zfs_prune panics v2

It turns out that approach taken in the original version of the patch
was wrong. So now, we're taking approach in-line with how kernel
actually does it - when sb is being torn down, access to it
is serialized via sb->s_umount rwsem, only when that lock is taken
is it okay to work with s_flags - and the other mistake I was doing
was trying to make SB_ACTIVE work, but apparently the kernel checks
the negative variant - not SB_DYING and not SB_BORN.

This way it finally seems to work without issues.

Signed-off-by: Pavel Snajdr <[email protected]>

Author: snajpa

module/os/linux/zfs/zpl_super.c

@@ -376,17 +376,15 @@ zpl_prune_sb(uint64_t nr_to_scan, void *arg)
 	int objects = 0;
 
 	/*
-	 * deactivate_locked_super calls shrinker_free and only then
-	 * sops->kill_sb cb, resulting in UAF on umount when trying to reach
-	 * for the shrinker functions in zpl_prune_sb of in-umount dataset.
-	 * Increment if s_active is not zero, but don't prune if it is -
-	 * umount could be underway.
+	 * Ensure the superblock is not in the process of being torn down.
 	 */
-	if (atomic_inc_not_zero(&sb->s_active)) {
-		(void) -zfs_prune(sb, nr_to_scan, &objects);
-		atomic_dec(&sb->s_active);
+	if (down_read_trylock(&sb->s_umount)) {
+		if (!(sb->s_flags & SB_DYING) && sb->s_root &&
+		    (sb->s_flags & SB_BORN)) {
+			(void) -zfs_prune(sb, nr_to_scan, &objects);
+		}
+		up_read(&sb->s_umount);
 	}
-
 }
 
 const struct super_operations zpl_super_operations = {