aboutsummaryrefslogtreecommitdiff
path: root/fs/namespace.c
AgeCommit message (Collapse)Author
2005-07-07[PATCH] set mnt_namespace in the correct placeMiklos Szeredi
This patch sets ->mnt_namespace where it's actually added to the namespace. Previously mnt_namespace was set in do_kern_mount() even if the filesystem was never added to any process's namespace (most kernel-internal filesystems). This discrepancy doesn't actually cause any problems, but it's cleaner if mnt_namespace is NULL for these non exported filesystems. Signed-off-by: Miklos Szeredi <miklos@szeredi.hu> Acked-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-07[PATCH] namespace.c: fix mnt_namespace zeroing for expired mountsMiklos Szeredi
This patch clears mnt_namespace in an expired mount. If mnt_namespace is not cleared, it's possible to attach a new mount to the already detached mount, because check_mnt() can return true. The effect is a resource leak, since the resulting tree will never be freed. Signed-off-by: Miklos Szeredi <miklos@szeredi.hu> Acked-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-07[PATCH] namespace.c: fix expiring of detached mountMiklos Szeredi
This patch fixes a bug noticed by Al Viro: However, we still have a problem here - just what would happen if vfsmount is detached while we were grabbing namespace semaphore? Refcount alone is not useful here - we might be held by whoever had detached the vfsmount. IOW, we should check that it's still attached (i.e. that mnt->mnt_parent != mnt). If it's not - just leave it alone, do mntput() and let whoever holds it deal with the sucker. No need to put it back on lists. Signed-off-by: Miklos Szeredi <miklos@szeredi.hu> Cc: <viro@parcelfarce.linux.theplanet.co.uk> Acked-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-07[PATCH] namespace.c: split mark_mounts_for_expiry()Miklos Szeredi
This patch splits the mark_mounts_for_expiry() function. It's too complex and too deeply nested, even without the bugfix in the following patch. Otherwise code is completely the same. Signed-off-by: Miklos Szeredi <miklos@szeredi.hu> Cc: <viro@parcelfarce.linux.theplanet.co.uk> Acked-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-07[PATCH] namespace.c: cleanup in mark_mounts_for_expiry()Miklos Szeredi
This patch simplifies mark_mounts_for_expiry() by using detach_mnt() instead of duplicating everything it does. It should be an equivalent transformation except for righting the dput/mntput order. Al Viro said: "Looks sane". Signed-off-by: Miklos Szeredi <miklos@szeredi.hu> Cc: <viro@parcelfarce.linux.theplanet.co.uk> Acked-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-07[PATCH] namespace.c: fix race in mark_mounts_for_expiry()Miklos Szeredi
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 was suggested by Al Viro, with his own words: Instead of screwing with atomic_read() in there, why don't we simply do the following: a) atomic_dec_and_lock() in put_namespace() b) __put_namespace() called without dropping lock c) the first thing done by __put_namespace would be struct vfsmount *root = namespace->root; namespace->root = NULL; spin_unlock(...); .... umount_tree(root); ... d) check in mark_... would be simply namespace && namespace->root. And we are all set; no screwing around with atomic_read(), no magic at all. Dying namespace gets NULL ->root. All changes of ->root happen under spinlock. If under a spinlock we see non-NULL ->mnt_namespace, it won't be freed until we drop the lock (we will set ->mnt_namespace to NULL under that lock before we get to freeing namespace). If under a spinlock we see non-NULL ->mnt_namespace and ->mnt_namespace->root, we can grab a reference to namespace and be sure that it won't go away. Signed-off-by: Miklos Szeredi <miklos@szeredi.hu> Acked-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Acked-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-07[PATCH] namespace.c: fix mnt_namespace clearingMiklos Szeredi
This patch clears mnt_namespace on unmount. Not clearing mnt_namespace has two effects: 1) It is possible to attach a new mount to a detached mount, because check_mnt() returns true. This means, that when no other references to the detached mount remain, it still can't be freed. This causes a resource leak, and possibly un-removable modules. 2) If mnt_namespace is dereferenced (only in mark_mounts_for_expiry()) after the namspace has been freed, it can cause an Oops, memory corruption, etc. 1) has been tested before and after the patch, 2) is only speculation. Signed-off-by: Miklos Szeredi <miklos@szeredi.hu> Acked-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-24[PATCH] make various thing staticAdrian Bunk
Another rollup of patches which give various symbols static scope Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!