1. 23 Jun, 2006 1 commit
    • David Howells's avatar
      [PATCH] VFS: Permit filesystem to override root dentry on mount · 454e2398
      David Howells authored
      Extend the get_sb() filesystem operation to take an extra argument that
      permits the VFS to pass in the target vfsmount that defines the mountpoint.
      The filesystem is then required to manually set the superblock and root dentry
      pointers.  For most filesystems, this should be done with simple_set_mnt()
      which will set the superblock pointer and then set the root dentry to the
      superblock's s_root (as per the old default behaviour).
      The get_sb() op now returns an integer as there's now no need to return the
      superblock pointer.
      This patch permits a superblock to be implicitly shared amongst several mount
      points, such as can be done with NFS to avoid potential inode aliasing.  In
      such a case, simple_set_mnt() would not be called, and instead the mnt_root
      and mnt_sb would be set directly.
      The patch also makes the following changes:
       (*) the get_sb_*() convenience functions in the core kernel now take a vfsmount
           pointer argument and return an integer, so most filesystems have to change
           very little.
       (*) If one of the convenience function is not used, then get_sb() should
           normally call simple_set_mnt() to instantiate the vfsmount. This will
           always return 0, and so can be tail-called from get_sb().
       (*) generic_shutdown_super() now calls shrink_dcache_sb() to clean up the
           dcache upon superblock destruction rather than shrink_dcache_anon().
           This is required because the superblock may now have multiple trees that
           aren't actually bound to s_root, but that still need to be cleaned up. The
           currently called functions assume that the whole tree is rooted at s_root,
           and that anonymous dentries are not the roots of trees which results in
           dentries being left unculled.
           However, with the way NFS superblock sharing are currently set to be
           implemented, these assumptions are violated: the root of the filesystem is
           simply a dummy dentry and inode (the real inode for '/' may well be
           inaccessible), and all the vfsmounts are rooted on anonymous[*] dentries
           with child trees.
           [*] Anonymous until discovered from another tree.
       (*) The documentation has been adjusted, including the additional bit of
           changing ext2_* into foo_* in the documentation.
      [akpm@osdl.org: convert ipath_fs, do other stuff]
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: Nathan Scott <nathans@sgi.com>
      Cc: Roland Dreier <rolandd@cisco.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  2. 22 Jun, 2006 5 commits
    • Andrew Morton's avatar
      [PATCH] prune_one_dentry() tweaks · d702ccb3
      Andrew Morton authored
      - Add description of d_lock handling to comments over prune_one_dentry().
      - It has three callsites - uninline it, saving 200 bytes of text.
      Cc: Jan Blunck <jblunck@suse.de>
      Cc: Kirill Korotaev <dev@openvz.org>
      Cc: Olaf Hering <olh@suse.de>
      Cc: Balbir Singh <balbir@in.ibm.com>
      Cc: Neil Brown <neilb@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • NeilBrown's avatar
      [PATCH] Fix dcache race during umount · 0feae5c4
      NeilBrown authored
      The race is that the shrink_dcache_memory shrinker could get called while a
      filesystem is being unmounted, and could try to prune a dentry belonging to
      that filesystem.
      If it does, then it will call in to iput on the inode while the dentry is
      no longer able to be found by the umounting process.  If iput takes a
      while, generic_shutdown_super could get all the way though
      shrink_dcache_parent and shrink_dcache_anon and invalidate_inodes without
      ever waiting on this particular inode.
      Eventually the superblock gets freed anyway and if the iput tried to touch
      it (which some filesystems certainly do), it will lose.  The promised
      "Self-destruct in 5 seconds" doesn't lead to a nice day.
      The race is closed by holding s_umount while calling prune_one_dentry on
      someone else's dentry.  As a down_read_trylock is used,
      shrink_dcache_memory will no longer try to prune the dentry of a filesystem
      that is being unmounted, and unmount will not be able to start until any
      such active prune_one_dentry completes.
      This requires that prune_dcache *knows* which filesystem (if any) it is
      doing the prune on behalf of so that it can be careful of other
      filesystems.  shrink_dcache_memory isn't called it on behalf of any
      filesystem, and so is careful of everything.
      shrink_dcache_anon is now passed a super_block rather than the s_anon list
      out of the superblock, so it can get the s_anon list itself, and can pass
      the superblock down to prune_dcache.
      If prune_dcache finds a dentry that it cannot free, it leaves it where it
      is (at the tail of the list) and exits, on the assumption that some other
      thread will be removing that dentry soon.  To try to make sure that some
      work gets done, a limited number of dnetries which are untouchable are
      skipped over while choosing the dentry to work on.
      I believe this race was first found by Kirill Korotaev.
      Cc: Jan Blunck <jblunck@suse.de>
      Acked-by: default avatarKirill Korotaev <dev@openvz.org>
      Cc: Olaf Hering <olh@suse.de>
      Acked-by: default avatarBalbir Singh <balbir@in.ibm.com>
      Signed-off-by: default avatarNeil Brown <neilb@suse.de>
      Signed-off-by: default avatarBalbir Singh <balbir@in.ibm.com>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Miklos Szeredi's avatar
      [PATCH] remove steal_locks() · c89681ed
      Miklos Szeredi authored
      This patch removes the steal_locks() function.
      steal_locks() doesn't work correctly with any filesystem that does it's own
      lock management, including NFS, CIFS, etc.
      In addition it has weird semantics on local filesystems in case tasks
      sharing file-descriptor tables are doing POSIX locking operations in
      parallel to execve().
      The steal_locks() function has an effect on applications doing:
        /* in child */
      POSIX locks acquired before execve (by "child", "parent" or any further
      task sharing files_struct) will after the execve be owned exclusively by
      According to Chris Wright some LSB/LTP kind of suite triggers without the
      stealing behavior, but there's no known real-world application that would
      also fail.
      Apps using NPTL are not affected, since all other threads are killed before
      Apps using LinuxThreads are only affected if they
        - have multiple threads during exec (LinuxThreads doesn't kill other
          threads, the app may do it with pthread_kill_other_threads_np())
        - rely on POSIX locks being inherited across exec
      Both conditions are documented, but not their interaction.
      Apps using clone() natively are affected if they
        - use clone(CLONE_FILES)
        - rely on POSIX locks being inherited across exec
      The above scenarios are unlikely, but possible.
      If the patch is vetoed, there's a plan B, that involves mostly keeping the
      weird stealing semantics, but changing the way lock ownership is handled so
      that network and local filesystems work consistently.
      That would add more complexity though, so this solution seems to be
      preferred by most people.
      Signed-off-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Matthew Wilcox <willy@debian.org>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Steven French <sfrench@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • OGAWA Hirofumi's avatar
      [PATCH] Fix a race condition between ->i_mapping and iput() · 09d967c6
      OGAWA Hirofumi authored
      This race became a cause of oops, and can reproduce by the following.
          while true; do
      	dd if=/dev/zero of=/dev/.static/dev/hdg1 bs=512 count=1000 & sync
      This race condition was between __sync_single_inode() and iput().
                cpu0 (fs's inode)                 cpu1 (bdev's inode)
                -----------------                 -------------------
         /* copy the bdev's ->i_mapping */
         mapping = inode->i_mapping;
      					     /* restre the fs's ->i_mapping */
      				             inode->i_mapping = &inode->i_data;
      				          /* bdev's inode was freed */
         if (wait) {
            /* dereference a freed bdev's mapping->host */
            filemap_fdatawait(mapping);  /* Oops */
      Since __sync_single_inode() is only taking a ref-count of fs's inode, the
      another process can be close() and freeing the bdev's inode while writing
      fs's inode.  So, __sync_signle_inode() accesses the freed ->i_mapping,
      This patch takes a ref-count on the bdev's inode for the fs's inode before
      setting a ->i_mapping, and the clear_inode() of the fs's inode does iput() on
      the bdev's inode.  So if the fs's inode is still living, bdev's inode
      shouldn't be freed.
      Signed-off-by: default avatarOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Anton Altaparmakov's avatar
      [PATCH] NTFS: Critical bug fix (affects MIPS and possibly others) · f893afbe
      Anton Altaparmakov authored
      Many thanks to Pauline Ng for the detailed bug report and analysis!
      Signed-off-by: default avatarAnton Altaparmakov <aia21@cantab.net>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  3. 21 Jun, 2006 1 commit
  4. 20 Jun, 2006 11 commits
  5. 18 Jun, 2006 8 commits
  6. 17 Jun, 2006 2 commits
  7. 14 Jun, 2006 1 commit
  8. 13 Jun, 2006 1 commit
  9. 09 Jun, 2006 10 commits