]> git.hungrycats.org Git - linux/commit
fsnotify: Fix busy inodes during unmount
authorJan Kara <jack@suse.cz>
Wed, 17 Oct 2018 11:07:05 +0000 (13:07 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 13 Nov 2018 19:08:50 +0000 (11:08 -0800)
commit778af261c53b0852ba5d9e2f45d4c03f46eddee6
tree903ec7b8bbc5edfeac56958716a24adeb578e17e
parenta94a2e3b59038e290956730741148e4173da3c5b
fsnotify: Fix busy inodes during unmount

commit 721fb6fbfd2132164c2e8777cc837f9b2c1794dc upstream.

Detaching of mark connector from fsnotify_put_mark() can race with
unmounting of the filesystem like:

  CPU1 CPU2
fsnotify_put_mark()
  spin_lock(&conn->lock);
  ...
  inode = fsnotify_detach_connector_from_object(conn)
  spin_unlock(&conn->lock);
generic_shutdown_super()
  fsnotify_unmount_inodes()
    sees connector detached for inode
      -> nothing to do
  evict_inode()
    barfs on pending inode reference
  iput(inode);

Resulting in "Busy inodes after unmount" message and possible kernel
oops. Make fsnotify_unmount_inodes() properly wait for outstanding inode
references from detached connectors.

Note that the accounting of outstanding inode references in the
superblock can cause some cacheline contention on the counter. OTOH it
happens only during deletion of the last notification mark from an inode
(or during unlinking of watched inode) and that is not too bad. I have
measured time to create & delete inotify watch 100000 times from 64
processes in parallel (each process having its own inotify group and its
own file on a shared superblock) on a 64 CPU machine. Average and
standard deviation of 15 runs look like:

Avg Stddev
Vanilla 9.817400 0.276165
Fixed 9.710467 0.228294

So there's no statistically significant difference.

Fixes: 6b3f05d24d35 ("fsnotify: Detach mark from object list when last reference is dropped")
CC: stable@vger.kernel.org
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/notify/fsnotify.c
fs/notify/mark.c
include/linux/fs.h