Commit Graph

108 Commits

Author SHA1 Message Date
Miklos Szeredi
ac0811538b [PATCH] namespace.c: fix mnt_namespace zeroing for expired mounts
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 18:23:51 -07:00
Miklos Szeredi
ed42c879b7 [PATCH] namespace.c: fix expiring of detached mount
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 18:23:51 -07:00
Miklos Szeredi
24ca2af1e7 [PATCH] namespace.c: split mark_mounts_for_expiry()
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 18:23:51 -07:00
Miklos Szeredi
a4d7027861 [PATCH] namespace.c: cleanup in mark_mounts_for_expiry()
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 18:23:51 -07:00
Miklos Szeredi
1ce88cf466 [PATCH] namespace.c: fix race in mark_mounts_for_expiry()
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 18:23:51 -07:00
Miklos Szeredi
202322e6f7 [PATCH] namespace.c: fix mnt_namespace clearing
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-07-07 18:23:51 -07:00
Adrian Bunk
52c1da3953 [PATCH] make various thing static
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-06-24 00:06:43 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00