1. 08 11月, 2005 13 次提交
  2. 11 9月, 2005 1 次提交
  3. 08 9月, 2005 2 次提交
  4. 08 8月, 2005 1 次提交
    • M
      [PATCH] namespace.c: fix bind mount from foreign namespace · 68b47139
      Miklos Szeredi 提交于
      I'm resending this patch, because I still believe it's the correct fix.
      
      Tested before/after applying the patch with a test application
      available from:
      
        http://www.inf.bme.hu/~mszeredi/nstest.c
      
      Bind mount from a foreign namespace results in an un-removable mount.
      The reason is that mnt->mnt_namespace is copied from the old mount in
      clone_mnt().  Because of this check_mnt() in sys_umount() will fail.
      
      The solution is to set mnt->mnt_namespace to current->namespace in
      clone_mnt().  clone_mnt() is either called from do_loopback() or
      copy_tree().  copy_tree() is called from do_loopback() or
      copy_namespace().
      
      When called (directly or indirectly) from do_loopback(), always
      current->namspace is being modified: check_mnt(nd->mnt).  So setting
      mnt->mnt_namespace to current->namspace is the right thing to do.
      
      When called from copy_namespace(), the setting of mnt_namespace is
      irrelevant, since mnt_namespace is reset later in that function for
      all copied mounts.
      
      Jamie said:
      
        This patch is correct.  The old code was buggy for more fundamental and
        serious reason: it broke the invariant that a tree of vfsmnts all have the
        same value of mnt_namespace (and the same for the mnt_list list).
      Signed-off-by: NMiklos Szeredi <miklos@szeredi.hu>
      Acked-by: NJamie Lokier <jamie@shareable.org>
      Cc: <viro@parcelfarce.linux.theplanet.co.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      68b47139
  5. 08 7月, 2005 8 次提交
  6. 24 6月, 2005 1 次提交
  7. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus 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!
      1da177e4