1. 23 3月, 2011 2 次提交
    • A
    • 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
  2. 15 3月, 2011 10 次提交
  3. 01 2月, 2011 2 次提交
    • T
      net/9p: replace p9_poll_task with a work · aa70c585
      Tejun Heo 提交于
      Now that cmwq can handle high concurrency, it's more efficient to use
      work than a dedicated kthread.  Convert p9_poll_proc() to a work
      function for p9_poll_work and make p9_pollwake() schedule it on each
      poll event.  The work is sync flushed on module exit.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Eric Van Hensbergen <ericvh@gmail.com>
      Cc: Ron Minnich <rminnich@sandia.gov>
      Cc: Latchesar Ionkov <lucho@ionkov.net>
      Cc: v9fs-developer@lists.sourceforge.net
      aa70c585
    • T
      net/9p: use system_wq instead of p9_mux_wq · 61edeeed
      Tejun Heo 提交于
      With cmwq, there's no reason to use a dedicated workqueue in trans_fd.
      Drop p9_mux_wq and use system_wq instead.  The used work items are
      already sync canceled in p9_conn_destroy() and doesn't require further
      synchronization.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Eric Van Hensbergen <ericvh@gmail.com>
      Cc: Ron Minnich <rminnich@sandia.gov>
      Cc: Latchesar Ionkov <lucho@ionkov.net>
      Cc: v9fs-developer@lists.sourceforge.net
      61edeeed
  4. 20 1月, 2011 1 次提交
  5. 11 1月, 2011 1 次提交
  6. 09 12月, 2010 1 次提交
  7. 28 10月, 2010 11 次提交
  8. 21 10月, 2010 1 次提交
  9. 28 9月, 2010 1 次提交
    • S
      net/9p: Mount only matching virtio channels · 0b20406c
      Sven Eckelmann 提交于
      p9_virtio_create will only compare the the channel's tag characters
      against the device name till the end of the channel's tag but not till
      the end of the device name. This means that if a user defines channels
      with the tags foo and foobar then he would mount foo when he requested
      foonot and may mount foo when he requested foobar.
      
      Thus it is necessary to check both string lengths against each other in
      case of a successful partial string match.
      Signed-off-by: NSven Eckelmann <sven.eckelmann@gmx.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b20406c
  10. 27 9月, 2010 1 次提交
  11. 24 9月, 2010 1 次提交
  12. 13 9月, 2010 1 次提交
  13. 07 9月, 2010 1 次提交
  14. 03 8月, 2010 6 次提交