> @@ -278,7 +325,12 @@ void generic_shutdown_super(struct super_block *sb) > { > const struct super_operations *sop = sb->s_op; > > - > + /* > + * shut down the shrinker first so we know that there are no possible > + * races when shrinking the dcache or icache. Removes the need for > + * external locking to prevent such races. > + */ > + unregister_shrinker(&sb->s_shrink); > if (sb->s_root) { > shrink_dcache_for_umount(sb); > sync_filesystem(sb); What it means is that shrinker_rwsem now nests inside ->s_umount... IOW, if any ->shrink() gets stuck, so does every generic_shutdown_super(). I'm still not convinced it's a good idea - especially since _this_ superblock will be skipped anyway. Is there any good reason to evict shrinker that early? Note that doing that after ->s_umount is dropped should be reasonably safe - your shrinker will see that superblock is doomed if it's called anywhere in that window... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html