Re: [BUG] Race with iput and umount

[viro]

On Sat, Oct 02, 2004 at 03:55:18AM -0400, Jeff Mahoney wrote:
> 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.

Arrgh...

Bug is in the ->i_count hacks in sys_unlink().  1001st proof that VFS has
no fscking business playing with inode refcount directly...

OK, quick and dirty fix follows.  Note: all places that go to exit1: or exit:
will have NULL inode, so we are not leaking anything here and it is OK do that
iput() early; indeed, the goal of that kludge was to postpone the final
iput() past the unlocking the parent for the sake of contention if a wunch
of bankers is doing parallel unlink() on files in the same directory and
normally it would happen on dput() after vfs_unlink())

--- linux/fs/namei.c	Mon Sep 13 01:32:00 2004
+++ linux/fs/namei.c.fix	Sat Oct  2 05:48:21 2004
@@ -1825,13 +1825,12 @@
 		dput(dentry);
 	}
 	up(&nd.dentry->d_inode->i_sem);
+	if (inode)
+		iput(inode);	/* truncate the inode here */
 exit1:
 	path_release(&nd);
 exit:
 	putname(name);
-
-	if (inode)
-		iput(inode);	/* truncate the inode here */
 	return error;
 
 slashes:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/