1. 01 2月, 2012 11 次提交
  2. 04 1月, 2012 2 次提交
  3. 19 10月, 2011 1 次提交
  4. 11 10月, 2011 1 次提交
  5. 02 7月, 2011 1 次提交
  6. 07 1月, 2011 3 次提交
    • N
      fs: dcache reduce branches in lookup path · fb045adb
      Nick Piggin 提交于
      Reduce some branches and memory accesses in dcache lookup by adding dentry
      flags to indicate common d_ops are set, rather than having to check them.
      This saves a pointer memory access (dentry->d_op) in common path lookup
      situations, and saves another pointer load and branch in cases where we
      have d_op but not the particular operation.
      
      Patched with:
      
      git grep -E '[.>]([[:space:]])*d_op([[:space:]])*=' | xargs sed -e 's/\([^\t ]*\)->d_op = \(.*\);/d_set_d_op(\1, \2);/' -e 's/\([^\t ]*\)\.d_op = \(.*\);/d_set_d_op(\&\1, \2);/' -i
      Signed-off-by: NNick Piggin <npiggin@kernel.dk>
      fb045adb
    • N
      fs: icache RCU free inodes · fa0d7e3d
      Nick Piggin 提交于
      RCU free the struct inode. This will allow:
      
      - Subsequent store-free path walking patch. The inode must be consulted for
        permissions when walking, so an RCU inode reference is a must.
      - sb_inode_list_lock to be moved inside i_lock because sb list walkers who want
        to take i_lock no longer need to take sb_inode_list_lock to walk the list in
        the first place. This will simplify and optimize locking.
      - Could remove some nested trylock loops in dcache code
      - Could potentially simplify things a bit in VM land. Do not need to take the
        page lock to follow page->mapping.
      
      The downsides of this is the performance cost of using RCU. In a simple
      creat/unlink microbenchmark, performance drops by about 10% due to inability to
      reuse cache-hot slab objects. As iterations increase and RCU freeing starts
      kicking over, this increases to about 20%.
      
      In cases where inode lifetimes are longer (ie. many inodes may be allocated
      during the average life span of a single inode), a lot of this cache reuse is
      not applicable, so the regression caused by this patch is smaller.
      
      The cache-hot regression could largely be avoided by using SLAB_DESTROY_BY_RCU,
      however this adds some complexity to list walking and store-free path walking,
      so I prefer to implement this at a later date, if it is shown to be a win in
      real situations. I haven't found a regression in any non-micro benchmark so I
      doubt it will be a problem.
      Signed-off-by: NNick Piggin <npiggin@kernel.dk>
      fa0d7e3d
    • N
      fs: change d_delete semantics · fe15ce44
      Nick Piggin 提交于
      Change d_delete from a dentry deletion notification to a dentry caching
      advise, more like ->drop_inode. Require it to be constant and idempotent,
      and not take d_lock. This is how all existing filesystems use the callback
      anyway.
      
      This makes fine grained dentry locking of dput and dentry lru scanning
      much simpler.
      Signed-off-by: NNick Piggin <npiggin@kernel.dk>
      fe15ce44
  7. 05 1月, 2011 1 次提交
    • T
      kernel panic when mount NFSv4 · beb0f0a9
      Trond Myklebust 提交于
      On Tue, 2010-12-14 at 16:58 +0800, Mi Jinlong wrote:
      > Hi,
      >
      > When testing NFSv4 at RHEL6 with kernel 2.6.32, I got a kernel panic
      > at NFS client's __rpc_create_common function.
      >
      > The panic place is:
      >   rpc_mkpipe
      >     __rpc_lookup_create()          <=== find pipefile *idmap*
      >     __rpc_mkpipe()                 <=== pipefile is *idmap*
      >       __rpc_create_common()
      >        ******  BUG_ON(!d_unhashed(dentry)); ******    *panic*
      >
      > It means that the dentry's d_flags have be set DCACHE_UNHASHED,
      > but it should not be set here.
      >
      > Is someone known this bug? or give me some idea?
      >
      > A reproduce program is append, but it can't reproduce the bug every time.
      > the export is: "/nfsroot       *(rw,no_root_squash,fsid=0,insecure)"
      >
      > And the panic message is append.
      >
      > ============================================================================
      > #!/bin/sh
      >
      > LOOPTOTAL=768
      > LOOPCOUNT=0
      > ret=0
      >
      > while [ $LOOPCOUNT -ne $LOOPTOTAL ]
      > do
      > 	((LOOPCOUNT += 1))
      > 	service nfs restart
      > 	/usr/sbin/rpc.idmapd
      > 	mount -t nfs4 127.0.0.1:/ /mnt|| return 1;
      > 	ls -l /var/lib/nfs/rpc_pipefs/nfs/*/
      > 	umount /mnt
      > 	echo $LOOPCOUNT
      > done
      >
      > ===============================================================================
      > Code: af 60 01 00 00 89 fa 89 f0 e8 64 cf 89 f0 e8 5c 7c 64 cf 31 c0 8b 5c 24 10 8b
      > 74 24 14 8b 7c 24 18 8b 6c 24 1c 83 c4 20 c3 <0f> 0b eb fc 8b 46 28 c7 44 24 08 20
      > de ee f0 c7 44 24 04 56 ea
      > EIP:[<f0ee92ea>] __rpc_create_common+0x8a/0xc0 [sunrpc] SS:ESP 0068:eccb5d28
      > ---[ end trace 8f5606cd08928ed2]---
      > Kernel panic - not syncing: Fatal exception
      > Pid:7131, comm: mount.nfs4 Tainted: G     D   -------------------2.6.32 #1
      > Call Trace:
      >  [<c080ad18>] ? panic+0x42/0xed
      >  [<c080e42c>] ? oops_end+0xbc/0xd0
      >  [<c040b090>] ? do_invalid_op+0x0/0x90
      >  [<c040b10f>] ? do_invalid_op+0x7f/0x90
      >  [<f0ee92ea>] ? __rpc_create_common+0x8a/0xc0[sunrpc]
      >  [<f0edc433>] ? rpc_free_task+0x33/0x70[sunrpc]
      >  [<f0ed6508>] ? prc_call_sync+0x48/0x60[sunrpc]
      >  [<f0ed656e>] ? rpc_ping+0x4e/0x60[sunrpc]
      >  [<f0ed6eaf>] ? rpc_create+0x38f/0x4f0[sunrpc]
      >  [<c080d80b>] ? error_code+0x73/0x78
      >  [<f0ee92ea>] ? __rpc_create_common+0x8a/0xc0[sunrpc]
      >  [<c0532bda>] ? d_lookup+0x2a/0x40
      >  [<f0ee94b1>] ? rpc_mkpipe+0x111/0x1b0[sunrpc]
      >  [<f10a59f4>] ? nfs_create_rpc_client+0xb4/0xf0[nfs]
      >  [<f10d6c6d>] ? nfs_fscache_get_client_cookie+0x1d/0x50[nfs]
      >  [<f10d3fcb>] ? nfs_idmap_new+0x7b/0x140[nfs]
      >  [<c05e76aa>] ? strlcpy+0x3a/0x60
      >  [<f10a60ca>] ? nfs4_set_client+0xea/0x2b0[nfs]
      >  [<f10a6d0c>] ? nfs4_create_server+0xac/0x1b0[nfs]
      >  [<c04f1400>] ? krealloc+0x40/0x50
      >  [<f10b0e8b>] ? nfs4_remote_get_sb+0x6b/0x250[nfs]
      >  [<c04f14ec>] ? kstrdup+0x3c/0x60
      >  [<c0520739>] ? vfs_kern_mount+0x69/0x170
      >  [<f10b1a3c>] ? nfs_do_root_mount+0x6c/0xa0[nfs]
      >  [<f10b1b47>] ? nfs4_try_mount+0x37/0xa0[nfs]
      >  [<f10afe6d>] ? nfs4_validate_text_mount_data+-x7d/0xf0[nfs]
      >  [<f10b1c42>] ? nfs4_get_sb+0x92/0x2f0
      >  [<c0520739>] ? vfs_kern_mount+0x69/0x170
      >  [<c05366d2>] ? get_fs_type+0x32/0xb0
      >  [<c052089f>] ? do_kern_mount+0x3f/0xe0
      >  [<c053954f>] ? do_mount+0x2ef/0x740
      >  [<c0537740>] ? copy_mount_options+0xb0/0x120
      >  [<c0539a0e>] ? sys_mount+0x6e/0xa0
      
      Hi,
      
      Does the following patch fix the problem?
      
      Cheers
        Trond
      
      --------------------------
      SUNRPC: Fix a BUG in __rpc_create_common
      
      From: Trond Myklebust <Trond.Myklebust@netapp.com>
      
      Mi Jinlong reports:
      
      When testing NFSv4 at RHEL6 with kernel 2.6.32, I got a kernel panic
      at NFS client's __rpc_create_common function.
      
      The panic place is:
        rpc_mkpipe
            __rpc_lookup_create()          <=== find pipefile *idmap*
            __rpc_mkpipe()                 <=== pipefile is *idmap*
              __rpc_create_common()
               ******  BUG_ON(!d_unhashed(dentry)); ****** *panic*
      
      The test is wrong: we can find ourselves with a hashed negative dentry here
      if the idmapper tried to look up the file before we got round to creating
      it.
      
      Just replace the BUG_ON() with a d_drop(dentry).
      Reported-by: NMi Jinlong <mijinlong@cn.fujitsu.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      beb0f0a9
  8. 29 10月, 2010 1 次提交
  9. 26 10月, 2010 1 次提交
    • C
      fs: do not assign default i_ino in new_inode · 85fe4025
      Christoph Hellwig 提交于
      Instead of always assigning an increasing inode number in new_inode
      move the call to assign it into those callers that actually need it.
      For now callers that need it is estimated conservatively, that is
      the call is added to all filesystems that do not assign an i_ino
      by themselves.  For a few more filesystems we can avoid assigning
      any inode number given that they aren't user visible, and for others
      it could be done lazily when an inode number is actually needed,
      but that's left for later patches.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      85fe4025
  10. 19 10月, 2010 1 次提交
  11. 23 9月, 2010 1 次提交
  12. 13 9月, 2010 2 次提交
  13. 22 5月, 2010 1 次提交
  14. 22 3月, 2010 1 次提交
  15. 04 3月, 2010 1 次提交
  16. 15 2月, 2010 1 次提交
  17. 24 9月, 2009 1 次提交
  18. 22 9月, 2009 1 次提交
  19. 20 8月, 2009 2 次提交
  20. 10 8月, 2009 6 次提交