1. 25 10月, 2011 4 次提交
  2. 23 7月, 2011 7 次提交
  3. 25 5月, 2011 2 次提交
  4. 10 5月, 2011 1 次提交
  5. 16 4月, 2011 2 次提交
  6. 13 4月, 2011 1 次提交
  7. 31 3月, 2011 1 次提交
  8. 23 3月, 2011 1 次提交
    • A
      net/9p: Convert the in the 9p rpc call path to GFP_NOFS · eeff66ef
      Aneesh Kumar K.V 提交于
      Without this we can cause reclaim allocation in writepage.
      
      [ 3433.448430] =================================
      [ 3433.449117] [ INFO: inconsistent lock state ]
      [ 3433.449117] 2.6.38-rc5+ #84
      [ 3433.449117] ---------------------------------
      [ 3433.449117] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage.
      [ 3433.449117] kswapd0/505 [HC0[0]:SC0[0]:HE1:SE1] takes:
      [ 3433.449117]  (iprune_sem){+++++-}, at: [<ffffffff810ebbab>] shrink_icache_memory+0x45/0x2b1
      [ 3433.449117] {RECLAIM_FS-ON-W} state was registered at:
      [ 3433.449117]   [<ffffffff8107fe5f>] mark_held_locks+0x52/0x70
      [ 3433.449117]   [<ffffffff8107ff02>] lockdep_trace_alloc+0x85/0x9f
      [ 3433.449117]   [<ffffffff810d353d>] slab_pre_alloc_hook+0x18/0x3c
      [ 3433.449117]   [<ffffffff810d3fd5>] kmem_cache_alloc+0x23/0xa2
      [ 3433.449117]   [<ffffffff8127be77>] idr_pre_get+0x2d/0x6f
      [ 3433.449117]   [<ffffffff815434eb>] p9_idpool_get+0x30/0xae
      [ 3433.449117]   [<ffffffff81540123>] p9_client_rpc+0xd7/0x9b0
      [ 3433.449117]   [<ffffffff815427b0>] p9_client_clunk+0x88/0xdb
      [ 3433.449117]   [<ffffffff811d56e5>] v9fs_evict_inode+0x3c/0x48
      [ 3433.449117]   [<ffffffff810eb511>] evict+0x1f/0x87
      [ 3433.449117]   [<ffffffff810eb5c0>] dispose_list+0x47/0xe3
      [ 3433.449117]   [<ffffffff810eb8da>] evict_inodes+0x138/0x14f
      [ 3433.449117]   [<ffffffff810d90e2>] generic_shutdown_super+0x57/0xe8
      [ 3433.449117]   [<ffffffff810d91e8>] kill_anon_super+0x11/0x50
      [ 3433.449117]   [<ffffffff811d4951>] v9fs_kill_super+0x49/0xab
      [ 3433.449117]   [<ffffffff810d926e>] deactivate_locked_super+0x21/0x46
      [ 3433.449117]   [<ffffffff810d9e84>] deactivate_super+0x40/0x44
      [ 3433.449117]   [<ffffffff810ef848>] mntput_no_expire+0x100/0x109
      [ 3433.449117]   [<ffffffff810f0aeb>] sys_umount+0x2f1/0x31c
      [ 3433.449117]   [<ffffffff8102c87b>] system_call_fastpath+0x16/0x1b
      [ 3433.449117] irq event stamp: 192941
      [ 3433.449117] hardirqs last  enabled at (192941): [<ffffffff81568dcf>] _raw_spin_unlock_irq+0x2b/0x30
      [ 3433.449117] hardirqs last disabled at (192940): [<ffffffff810b5f97>] shrink_inactive_list+0x290/0x2f5
      [ 3433.449117] softirqs last  enabled at (188470): [<ffffffff8105fd65>] __do_softirq+0x133/0x152
      [ 3433.449117] softirqs last disabled at (188455): [<ffffffff8102d7cc>] call_softirq+0x1c/0x28
      [ 3433.449117]
      [ 3433.449117] other info that might help us debug this:
      [ 3433.449117] 1 lock held by kswapd0/505:
      [ 3433.449117]  #0:  (shrinker_rwsem){++++..}, at: [<ffffffff810b52e2>] shrink_slab+0x38/0x15f
      [ 3433.449117]
      [ 3433.449117] stack backtrace:
      [ 3433.449117] Pid: 505, comm: kswapd0 Not tainted 2.6.38-rc5+ #84
      [ 3433.449117] Call Trace:
      [ 3433.449117]  [<ffffffff8107fbce>] ? valid_state+0x17e/0x191
      [ 3433.449117]  [<ffffffff81036896>] ? save_stack_trace+0x28/0x45
      [ 3433.449117]  [<ffffffff81080426>] ? check_usage_forwards+0x0/0x87
      [ 3433.449117]  [<ffffffff8107fcf4>] ? mark_lock+0x113/0x22c
      [ 3433.449117]  [<ffffffff8108105f>] ? __lock_acquire+0x37a/0xcf7
      [ 3433.449117]  [<ffffffff8107fc0e>] ? mark_lock+0x2d/0x22c
      [ 3433.449117]  [<ffffffff81081077>] ? __lock_acquire+0x392/0xcf7
      [ 3433.449117]  [<ffffffff810b14d2>] ? determine_dirtyable_memory+0x15/0x28
      [ 3433.449117]  [<ffffffff81081a33>] ? lock_acquire+0x57/0x6d
      [ 3433.449117]  [<ffffffff810ebbab>] ? shrink_icache_memory+0x45/0x2b1
      [ 3433.449117]  [<ffffffff81567d85>] ? down_read+0x47/0x5c
      [ 3433.449117]  [<ffffffff810ebbab>] ? shrink_icache_memory+0x45/0x2b1
      [ 3433.449117]  [<ffffffff810ebbab>] ? shrink_icache_memory+0x45/0x2b1
      [ 3433.449117]  [<ffffffff810b5385>] ? shrink_slab+0xdb/0x15f
      [ 3433.449117]  [<ffffffff810b69bc>] ? kswapd+0x574/0x96a
      [ 3433.449117]  [<ffffffff810b6448>] ? kswapd+0x0/0x96a
      [ 3433.449117]  [<ffffffff810714e2>] ? kthread+0x7d/0x85
      [ 3433.449117]  [<ffffffff8102d6d4>] ? kernel_thread_helper+0x4/0x10
      [ 3433.449117]  [<ffffffff81569200>] ? restore_args+0x0/0x30
      [ 3433.449117]  [<ffffffff81071465>] ? kthread+0x0/0x85
      [ 3433.449117]  [<ffffffff8102d6d0>] ? kernel_thread_helper+0x0/0x10
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NVenkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      eeff66ef
  9. 15 3月, 2011 6 次提交
  10. 28 10月, 2010 10 次提交
  11. 21 10月, 2010 1 次提交
  12. 24 9月, 2010 1 次提交
  13. 13 9月, 2010 1 次提交
  14. 03 8月, 2010 2 次提交
    • A
      fs/9p: destroy fid on failed remove · 0b1208b1
      Aneesh Kumar K.V 提交于
      9P spec says:
      "It is correct to consider remove to be a clunk with the
      side effect of removing the file if permissions allow. "
      
      So even if remove fails we need to destroy the fid.
      
      Without this patch an rmdir on a directory with contents leave
      the new cloned directory fid fid attached to fidlist. On umount
      we dump the fids on the fidlist
      
      ~# rmdir /mnt2/test4/
      rmdir: failed to remove `/mnt2/test4/': Directory not empty
      ~# umount /mnt2/
      ~# dmesg
      [  228.474323] Found fid 3 not clunked
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NVenkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      0b1208b1
    • A
      net/9p: Implement TXATTRCREATE 9p call · eda25e46
      Aneesh Kumar K.V 提交于
      TXATTRCREATE:  Prepare a fid for setting xattr value on a file system object.
      
       size[4] TXATTRCREATE tag[2] fid[4] name[s] attr_size[8] flags[4]
       size[4] RXATTRCREATE tag[2]
      
      txattrcreate gets a fid pointing to xattr. This fid can later be
      used to set the xattr value.
      
      flag value is derived from set Linux setxattr. The manpage says
      "The flags parameter can be used to refine the semantics of the operation.
      XATTR_CREATE specifies a pure create, which fails if the named attribute
      exists already. XATTR_REPLACE specifies a pure replace operation, which
      fails if the named attribute does not already exist. By default (no flags),
      the extended attribute will be created if need be, or will simply replace
      the value if the attribute exists."
      
      The actual setxattr operation happens when the fid is clunked. At that point
      the written byte count and the attr_size specified in TXATTRCREATE should be
      same otherwise an error will be returned.
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NVenkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      eda25e46