Re: [PATCH 2/2] fs: call fsnotify_sb_delete after evict_inodes

[Al Viro <viro@zeniv.linux.org.uk>]

On Thu, Nov 07, 2019 at 02:52:34PM -0600, Eric Sandeen wrote:
> When a filesystem is unmounted, we currently call fsnotify_sb_delete()
> before evict_inodes(), which means that fsnotify_unmount_inodes()
> must iterate over all inodes on the superblock, even though it will
> only act on inodes with a refcount.  This is inefficient and can lead
> to livelocks as it iterates over many unrefcounted inodes.
> 
> However, since fsnotify_sb_delete() and evict_inodes() are working
> on orthogonal sets of inodes (fsnotify_sb_delete() only cares about
> nonzero refcount, and evict_inodes() only cares about zero refcount),
> we can swap the order of the calls.  The fsnotify call will then have
> a much smaller list to walk (any refcounted inodes).
> 
> This should speed things up overall, and avoid livelocks in
> fsnotify_unmount_inodes().

Umm...  The critical part you've omitted here is that at this stage
any final iput() done by fsnotify_sb_delete() (or anybody else,
really) will forcibly evict the sucker there and then.  So it's not
as if any inodes were *added* to the evictable set by
fsnotify_sb_delete() to be picked by evict_inodes() - any candidate
is immediately disposed of.  The crucial point is that SB_ACTIVE
is already cleared by that stage - without that the patch would've
been badly broken.

That aside, both patches look sane.  Could you update the commit
message and resend the second one?