1. 09 6月, 2006 1 次提交
  2. 20 4月, 2006 1 次提交
  3. 29 3月, 2006 1 次提交
  4. 21 3月, 2006 3 次提交
  5. 10 1月, 2006 1 次提交
  6. 07 1月, 2006 1 次提交
  7. 04 12月, 2005 1 次提交
  8. 05 11月, 2005 1 次提交
  9. 28 10月, 2005 3 次提交
  10. 19 10月, 2005 4 次提交
  11. 24 9月, 2005 2 次提交
  12. 20 8月, 2005 1 次提交
  13. 19 8月, 2005 3 次提交
    • C
      [PATCH] NFS: Introduce the use of inode->i_lock to protect fields in nfsi · dc59250c
      Chuck Lever 提交于
      Down the road we want to eliminate the use of the global kernel lock entirely
      from the NFS client.  To do this, we need to protect the fields in the
      nfs_inode structure adequately.  Start by serializing updates to the
      "cache_validity" field.
      
      Note this change addresses an SMP hang found by njw@osdl.org, where processes
      deadlock because nfs_end_data_update and nfs_revalidate_mapping update the
      "cache_validity" field without proper serialization.
      
      Test plan:
       Millions of fsx ops on SMP clients.  Run Nick Wilson's breaknfs program on
       large SMP clients.
      Signed-off-by: NChuck Lever <cel@netapp.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dc59250c
    • C
      [PATCH] NFS: use atomic bitops to manipulate flags in nfsi->flags · 412d582e
      Chuck Lever 提交于
      Introduce atomic bitops to manipulate the bits in the nfs_inode structure's
      "flags" field.
      
      Using bitops means we can use a generic wait_on_bit call instead of an ad hoc
      locking scheme in fs/nfs/inode.c, so we can remove the "nfs_i_wait" field from
      nfs_inode at the same time.
      
      The other new flags field will continue to use bitmask and logic AND and OR.
      This permits several flags to be set at the same time efficiently.  The
      following patch adds a spin lock to protect these flags, and this spin lock
      will later cover other fields in the nfs_inode structure, amortizing the cost
      of using this type of serialization.
      
      Test plan:
       Millions of fsx ops on SMP clients.
      Signed-off-by: NChuck Lever <cel@netapp.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      412d582e
    • C
      [PATCH] NFS: split nfsi->flags into two fields · 55296809
      Chuck Lever 提交于
      Certain bits in nfsi->flags can be manipulated with atomic bitops, and some
      are better manipulated via logical bitmask operations.
      
      This patch splits the flags field into two.  The next patch introduces atomic
      bitops for one of the fields.
      
      Test plan:
       Millions of fsx ops on SMP clients.
      Signed-off-by: NChuck Lever <cel@netapp.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      55296809
  14. 23 6月, 2005 6 次提交
  15. 08 6月, 2005 1 次提交
    • T
      [PATCH] NFS: Fix lookup intent handling · 1d6757fb
      Trond Myklebust 提交于
      We should never apply a lookup intent to anything other than the last
      path component in an open(), create() or access() call.
      
      Introduce the helper nfs_lookup_check_intent() which always returns
      zero if LOOKUP_CONTINUE or LOOKUP_PARENT are set, and returns the
      intent flags if we're on the last component of the lookup.
      By doing so, we fix a bug in open(O_EXCL), where we may end up
      optimizing away a real lookup of the parent directory.
      
      Problem noticed by Linda Dunaphant <linda.dunaphant@ccur.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1d6757fb
  16. 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