1. 29 10月, 2010 1 次提交
    • A
      fix open/umount race · d893f1bc
      Al Viro 提交于
      nameidata_to_filp() drops nd->path or transfers it to opened
      file.  In the former case it's a Bad Idea(tm) to do mnt_drop_write()
      on nd->path.mnt, since we might race with umount and vfsmount in
      question might be gone already.
      
      Fix: don't drop it, then...  IOW, have nameidata_to_filp() grab nd->path
      in case it transfers it to file and do path_drop() in callers.  After
      they are through with accessing nd->path...
      Reported-by: NMiklos Szeredi <miklos@szeredi.hu>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d893f1bc
  2. 26 10月, 2010 2 次提交
  3. 18 8月, 2010 4 次提交
    • N
      fs: brlock vfsmount_lock · 99b7db7b
      Nick Piggin 提交于
      fs: brlock vfsmount_lock
      
      Use a brlock for the vfsmount lock. It must be taken for write whenever
      modifying the mount hash or associated fields, and may be taken for read when
      performing mount hash lookups.
      
      A new lock is added for the mnt-id allocator, so it doesn't need to take
      the heavy vfsmount write-lock.
      
      The number of atomics should remain the same for fastpath rlock cases, though
      code would be slightly slower due to per-cpu access. Scalability is not not be
      much improved in common cases yet, due to other locks (ie. dcache_lock) getting
      in the way. However path lookups crossing mountpoints should be one case where
      scalability is improved (currently requiring the global lock).
      
      The slowpath is slower due to use of brlock. On a 64 core, 64 socket, 32 node
      Altix system (high latency to remote nodes), a simple umount microbenchmark
      (mount --bind mnt mnt2 ; umount mnt2 loop 1000 times), before this patch it
      took 6.8s, afterwards took 7.1s, about 5% slower.
      
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: NNick Piggin <npiggin@kernel.dk>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      99b7db7b
    • N
      fs: remove extra lookup in __lookup_hash · b04f784e
      Nick Piggin 提交于
      fs: remove extra lookup in __lookup_hash
      
      Optimize lookup for create operations, where no dentry should often be
      common-case. In cases where it is not, such as unlink, the added overhead
      is much smaller than the removed.
      
      Also, move comments about __d_lookup racyness to the __d_lookup call site.
      d_lookup is intuitive; __d_lookup is what needs commenting. So in that same
      vein, add kerneldoc comments to __d_lookup and clean up some of the comments:
      
      - We are interested in how the RCU lookup works here, particularly with
        renames. Make that explicit, and point to the document where it is explained
        in more detail.
      - RCU is pretty standard now, and macros make implementations pretty mindless.
        If we want to know about RCU barrier details, we look in RCU code.
      - Delete some boring legacy comments because we don't care much about how the
        code used to work, more about the interesting parts of how it works now. So
        comments about lazy LRU may be interesting, but would better be done in the
        LRU or refcount management code.
      Signed-off-by: NNick Piggin <npiggin@kernel.dk>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      b04f784e
    • N
      fs: dentry allocation consolidation · baa03890
      Nick Piggin 提交于
      fs: dentry allocation consolidation
      
      There are 2 duplicate copies of code in dentry allocation in path lookup.
      Consolidate them into a single function.
      Signed-off-by: NNick Piggin <npiggin@kernel.dk>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      baa03890
    • N
      fs: fix do_lookup false negative · 2e2e88ea
      Nick Piggin 提交于
      fs: fix do_lookup false negative
      
      In do_lookup, if we initially find no dentry, we take the directory i_mutex and
      re-check the lookup. If we find a dentry there, then we revalidate it if
      needed. However if that revalidate asks for the dentry to be invalidated, we
      return -ENOENT from do_lookup. What should happen instead is an attempt to
      allocate and lookup a new dentry.
      
      This is probably not noticed because it is rare. It is only reached if a
      concurrent create races in first (in which case, the dentry probably won't be
      invalidated anyway), or if the racy __d_lookup has failed due to a
      false-negative (which is very rare).
      
      Fix this by removing code and have it use the normal reval path.
      Signed-off-by: NNick Piggin <npiggin@kernel.dk>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      2e2e88ea
  4. 11 8月, 2010 1 次提交
  5. 02 8月, 2010 2 次提交
  6. 28 7月, 2010 1 次提交
    • E
      fsnotify: use unsigned char * for dentry->d_name.name · 59b0df21
      Eric Paris 提交于
      fsnotify was using char * when it passed around the d_name.name string
      internally but it is actually an unsigned char *.  This patch switches
      fsnotify to use unsigned and should silence some pointer signess warnings
      which have popped out of xfs.  I do not add -Wpointer-sign to the fsnotify
      code as there are still issues with kstrdup and strlen which would pop
      out needless warnings.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      59b0df21
  7. 28 5月, 2010 1 次提交
    • N
      VFS: fix recent breakage of FS_REVAL_DOT · 176306f5
      Neil Brown 提交于
      Commit 1f36f774 broke FS_REVAL_DOT semantics.
      
      In particular, before this patch, the command
         ls -l
      in an NFS mounted directory would always check if the directory on the server
      had changed and if so would flush and refill the pagecache for the dir.
      After this patch, the same "ls -l" will repeatedly return stale date until
      the cached attributes for the directory time out.
      
      The following patch fixes this by ensuring the d_revalidate is called by
      do_last when "." is being looked-up.
      link_path_walk has already called d_revalidate, but in that case LOOKUP_OPEN
      is not set so nfs_lookup_verify_inode chooses not to do any validation.
      
      The following patch restores the original behaviour.
      
      Cc: stable@kernel.org
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      176306f5
  8. 22 5月, 2010 1 次提交
  9. 15 5月, 2010 1 次提交
    • A
      Fix the regression created by "set S_DEAD on unlink()..." commit · d83c49f3
      Al Viro 提交于
      1) i_flags simply doesn't work for mount/unlink race prevention;
      we may have many links to file and rm on one of those obviously
      shouldn't prevent bind on top of another later on.  To fix it
      right way we need to mark _dentry_ as unsuitable for mounting
      upon; new flag (DCACHE_CANT_MOUNT) is protected by d_flags and
      i_mutex on the inode in question.  Set it (with dont_mount(dentry))
      in unlink/rmdir/etc., check (with cant_mount(dentry)) in places
      in namespace.c that used to check for S_DEAD.  Setting S_DEAD
      is still needed in places where we used to set it (for directories
      getting killed), since we rely on it for readdir/rmdir race
      prevention.
      
      2) rename()/mount() protection has another bogosity - we unhash
      the target before we'd checked that it's not a mountpoint.  Fixed.
      
      3) ancient bogosity in pivot_root() - we locked i_mutex on the
      right directory, but checked S_DEAD on the different (and wrong)
      one.  Noticed and fixed.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d83c49f3
  10. 13 5月, 2010 1 次提交
  11. 27 3月, 2010 1 次提交
  12. 07 3月, 2010 1 次提交
  13. 05 3月, 2010 19 次提交
  14. 04 3月, 2010 3 次提交
  15. 19 2月, 2010 1 次提交