[BUG] Race with iput and umount

[Jeff Mahoney <jeffm@novell.com>]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hey all -

There is currently no method in the superblock shutdown path to
determine if all inodes associated with the superblock are completely
quiesced. invalidate_inodes() will attempt to flush out inodes still
hanging around, but if inodes are in the iput() path, it's possible for
them to be removed from the inode list and in the ->delete_inode fs
method, which isn't protected by inode_lock any longer.
generic_shutdown_super() will happily call the ->put_super fs method,
destroying data structures still in use by the iput (->delete_inode) in
progress.  That's where Oopsen come into play.

The unlink path will call the ->unlink fs method, release the path (thus
dropping the reference to the vfsmount, and then call iput. Since the
vfsmount reference is dropped back to 1, a umount will succeed, causing
the superblock to be cleaned up.

This doesn't trigger during read/write or if pwd is inside the
filesystem, since open files and working directories also cause an
incremented vfsmount->mnt_count.

I've triggered Oopsen on 2.6.5, 2.6.8, 2.6.9-rc2, and 2.6.9-rc3 using
reiserfs, ext2, and ext3. Presumably, most (all?) 2.6 should be susceptible.

Attached is a script I've used to reliably trigger this bug. I'll
continue to track this down, but figured I'd post a heads up so more
eyes would see it.

- -Jeff

- --
Jeff Mahoney
SuSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBXl7mLPWxlyuTD7IRAu3VAJ4r/sFAX6dOr6WMpLh6YykmhBxo7gCgoluP
dpoTUfCqGZIVWeFJ1rc8yOI=
=lj86
-----END PGP SIGNATURE-----

[-- Attachment #2: 45004.sh --]
[-- Type: application/x-sh, Size: 292 bytes --]