1. 26 May, 2011 13 commits
    • Miklos Szeredi's avatar
      vfs: fix vfs_rename_dir for FS_RENAME_DOES_D_MOVE filesystems · b5afd2c4
      Miklos Szeredi authored
      vfs_rename_dir() doesn't properly account for filesystems with
      FS_RENAME_DOES_D_MOVE.  If new_dentry has a target inode attached, it
      unhashes the new_dentry prior to the rename() iop and rehashes it after,
      but doesn't account for the possibility that rename() may have swapped
      {old,new}_dentry.  For FS_RENAME_DOES_D_MOVE filesystems, it rehashes
      new_dentry (now the old renamed-from name, which d_move() expected to go
      away), such that a subsequent lookup will find it.  Currently all
      FS_RENAME_DOES_D_MOVE filesystems compensate for this by failing in
      d_revalidate.
      
      The bug was introduced by: commit 349457cc
      "[PATCH] Allow file systems to manually d_move() inside of ->rename()"
      
      Fix by not rehashing the new dentry.  Rehashing used to be needed by
      d_move() but isn't anymore.
      Reported-by: default avatarSage Weil <sage@newdream.net>
      Signed-off-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      b5afd2c4
    • Sage Weil's avatar
      libfs: drop unneeded dentry_unhash · 5c5d3f3b
      Sage Weil authored
      There are no libfs issues with dangling references to empty directories.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      5c5d3f3b
    • Sage Weil's avatar
      vfs: update dentry_unhash() comment · a71905f0
      Sage Weil authored
      The helper is now only called by file systems, not the VFS.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      a71905f0
    • Sage Weil's avatar
      vfs: push dentry_unhash on rename_dir into file systems · e4eaac06
      Sage Weil authored
      Only a few file systems need this.  Start by pushing it down into each
      rename method (except gfs2 and xfs) so that it can be dealt with on a
      per-fs basis.
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      e4eaac06
    • Sage Weil's avatar
      vfs: push dentry_unhash on rmdir into file systems · 79bf7c73
      Sage Weil authored
      Only a few file systems need this.  Start by pushing it down into each
      fs rmdir method (except gfs2 and xfs) so it can be dealt with on a per-fs
      basis.
      
      This does not change behavior for any in-tree file systems.
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      79bf7c73
    • Sage Weil's avatar
      vfs: remove dget() from dentry_unhash() · 64252c75
      Sage Weil authored
      This serves no useful purpose that I can discern.  All callers (rename,
      rmdir) hold their own reference to the dentry.
      
      A quick audit of all file systems showed no relevant checks on the value
      of d_count in vfs_rmdir/vfs_rename_dir paths.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      64252c75
    • Sage Weil's avatar
      vfs: dentry_unhash immediately prior to rmdir · 48293699
      Sage Weil authored
      This presumes that there is no reason to unhash a dentry if we fail because
      it is a mountpoint or the LSM check fails, and that the LSM checks do not
      depend on the dentry being unhashed.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      48293699
    • Jan Kara's avatar
      vfs: Block mmapped writes while the fs is frozen · ea13a864
      Jan Kara authored
      We should not allow file modification via mmap while the filesystem is
      frozen. So block in block_page_mkwrite() while the filesystem is frozen.
      We cannot do the blocking wait in __block_page_mkwrite() since e.g. ext4
      will want to call that function with transaction started in some cases
      and that would deadlock. But we can at least do the non-blocking reliable
      check in __block_page_mkwrite() which is the hardest part anyway.
      
      We have to check for frozen filesystem with the page marked dirty and under
      page lock with which we then return from ->page_mkwrite(). Only that way we
      cannot race with writeback done by freezing code - either we mark the page
      dirty after the writeback has started, see freezing in progress and block, or
      writeback will wait for our page lock which is released only when the fault is
      done and then writeback will writeout and writeprotect the page again.
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      ea13a864
    • Jan Kara's avatar
      vfs: Create __block_page_mkwrite() helper passing error values back · 24da4fab
      Jan Kara authored
      Create __block_page_mkwrite() helper which does all what block_page_mkwrite()
      does except that it passes back errors from __block_write_begin /
      block_commit_write calls.
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      24da4fab
    • Roman Borisov's avatar
      fs/namespace.c: bound mount propagation fix · 7c6e984d
      Roman Borisov authored
      This issue was discovered by users of busybox.  And the bug is actual for
      busybox users, I don't know how it affects others.  Apparently, mount is
      called with and without MS_SILENT, and this affects mount() behaviour.
      But MS_SILENT is only supposed to affect kernel logging verbosity.
      
      The following script was run in an empty test directory:
      
      mkdir -p mount.dir mount.shared1 mount.shared2
      touch mount.dir/a mount.dir/b
      mount -vv --bind         mount.shared1 mount.shared1
      mount -vv --make-rshared mount.shared1
      mount -vv --bind         mount.shared2 mount.shared2
      mount -vv --make-rshared mount.shared2
      mount -vv --bind mount.shared2 mount.shared1
      mount -vv --bind mount.dir     mount.shared2
      ls -R mount.dir mount.shared1 mount.shared2
      umount mount.dir mount.shared1 mount.shared2 2>/dev/null
      umount mount.dir mount.shared1 mount.shared2 2>/dev/null
      umount mount.dir mount.shared1 mount.shared2 2>/dev/null
      rm -f mount.dir/a mount.dir/b mount.dir/c
      rmdir mount.dir mount.shared1 mount.shared2
      
      mount -vv was used to show the mount() call arguments and result.
      Output shows that flag argument has 0x00008000 = MS_SILENT bit:
      
      mount: mount('mount.shared1','mount.shared1','(null)',0x00009000,'(null)'):0
      mount: mount('','mount.shared1','',0x0010c000,''):0
      mount: mount('mount.shared2','mount.shared2','(null)',0x00009000,'(null)'):0
      mount: mount('','mount.shared2','',0x0010c000,''):0
      mount: mount('mount.shared2','mount.shared1','(null)',0x00009000,'(null)'):0
      mount: mount('mount.dir','mount.shared2','(null)',0x00009000,'(null)'):0
      mount.dir:
      a
      b
      
      mount.shared1:
      
      mount.shared2:
      a
      b
      
      After adding --loud option to remove MS_SILENT bit from just one mount cmd:
      
      mkdir -p mount.dir mount.shared1 mount.shared2
      touch mount.dir/a mount.dir/b
      mount -vv --bind         mount.shared1 mount.shared1 2>&1
      mount -vv --make-rshared mount.shared1               2>&1
      mount -vv --bind         mount.shared2 mount.shared2 2>&1
      mount -vv --loud --make-rshared mount.shared2               2>&1  # <-HERE
      mount -vv --bind mount.shared2 mount.shared1         2>&1
      mount -vv --bind mount.dir     mount.shared2         2>&1
      ls -R mount.dir mount.shared1 mount.shared2      2>&1
      umount mount.dir mount.shared1 mount.shared2 2>/dev/null
      umount mount.dir mount.shared1 mount.shared2 2>/dev/null
      umount mount.dir mount.shared1 mount.shared2 2>/dev/null
      rm -f mount.dir/a mount.dir/b mount.dir/c
      rmdir mount.dir mount.shared1 mount.shared2
      
      The result is different now - look closely at mount.shared1 directory listing.
      Now it does show files 'a' and 'b':
      
      mount: mount('mount.shared1','mount.shared1','(null)',0x00009000,'(null)'):0
      mount: mount('','mount.shared1','',0x0010c000,''):0
      mount: mount('mount.shared2','mount.shared2','(null)',0x00009000,'(null)'):0
      mount: mount('','mount.shared2','',0x00104000,''):0
      mount: mount('mount.shared2','mount.shared1','(null)',0x00009000,'(null)'):0
      mount: mount('mount.dir','mount.shared2','(null)',0x00009000,'(null)'):0
      
      mount.dir:
      a
      b
      
      mount.shared1:
      a
      b
      
      mount.shared2:
      a
      b
      
      The analysis shows that MS_SILENT flag which is ON by default in any
      busybox-> mount operations cames to flags_to_propagation_type function and
      causes the error return while is_power_of_2 checking because the function
      expects only one bit set.  This doesn't allow to do busybox->mount with
      any --make-[r]shared, --make-[r]private etc options.
      
      Moreover, the recently added flags_to_propagation_type() function doesn't
      allow us to do such operations as --make-[r]private --make-[r]shared etc.
      when MS_SILENT is on.  The idea or clearing the MS_SILENT flag came from
      to Denys Vlasenko.
      Signed-off-by: default avatarRoman Borisov <ext-roman.borisov@nokia.com>
      Reported-by: default avatarDenys Vlasenko <vda.linux@googlemail.com>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Cc: Alexander Shishkin <virtuoso@slind.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      7c6e984d
    • Jonas Gorski's avatar
      exportfs: reallow building as a module · 79fead47
      Jonas Gorski authored
      Commit 990d6c2d ("vfs: Add name to file
      handle conversion support") changed EXPORTFS to be a bool.
      This was needed for earlier revisions of the original patch, but the actual
      commit put the code needing it into its own file that only gets compiled
      when FHANDLE is selected which in turn selects EXPORTFS.
      So EXPORTFS can be safely compiled as a module when not selecting FHANDLE.
      Signed-off-by: default avatarJonas Gorski <jonas.gorski@gmail.com>
      Acked-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      79fead47
    • Al Viro's avatar
      merge handle_reval_dot and nameidata_drop_rcu_last · 9f1fafee
      Al Viro authored
      new helper: complete_walk().  Done on successful completion
      of walk, drops out of RCU mode, does d_revalidate of final
      result if that hadn't been done already.
      
      handle_reval_dot() and nameidata_drop_rcu_last() subsumed into
      that one; callers converted to use of complete_walk().
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      9f1fafee
    • Al Viro's avatar
      consolidate nameidata_..._drop_rcu() · 19660af7
      Al Viro authored
      Merge these into a single function (unlazy_walk(nd, dentry)),
      kill ..._maybe variants
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      19660af7
  2. 29 Apr, 2011 12 commits
  3. 28 Apr, 2011 15 commits