[PATCH retry] namespace.c: fix race in mark_mounts_for_expiry()

[Miklos Szeredi <miklos@szeredi.hu>]

One more try.  I hope everybody's happy now.

This patch fixes a race found by Ram in mark_mounts_for_expiry() in
fs/namespace.c.

The bug can only be triggered with simultaneous exiting of a process
having a private namespace, and expiry of a mount from within that
namespace.  It's practically impossible to trigger, and I haven't even
tried.  But still, a bug is a bug.

The race happens when put_namespace() is called by another task, while
mark_mounts_for_expiry() is between atomic_read() and get_namespace().
In that case get_namespace() will be called on an already dead
namespace with unforeseeable results.

The solution is to use atomic_dec_and_lock() in put_namespace() as
suggested by Al Viro.

This is a mininal fix, really only serving as a reminder, that this
usage of mnt_namespace is ugly and needs to be properly cleaned up.

Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>

Index: linux/include/linux/namespace.h
===================================================================
--- linux.orig/include/linux/namespace.h	2005-05-19 12:50:49.000000000 +0200
+++ linux/include/linux/namespace.h	2005-05-20 11:52:40.000000000 +0200
@@ -14,11 +14,17 @@ struct namespace {
 
 extern int copy_namespace(int, struct task_struct *);
 extern void __put_namespace(struct namespace *namespace);
+extern spinlock_t vfsmount_lock;
 
 static inline void put_namespace(struct namespace *namespace)
 {
-	if (atomic_dec_and_test(&namespace->count))
+	/* Seemingly unnecessary taking of vfsmount_lock, needed to
+	   protect atomicity of atomic_read()/get_namespace() wrt
+	   count going to zero in mark_mounts_for_expiry() */
+	if (atomic_dec_and_lock(&namespace->count, &vfsmount_lock)) {
+		spin_unlock(&vfsmount_lock);
 		__put_namespace(namespace);
+	}
 }
 
 static inline void exit_namespace(struct task_struct *p)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/