1. 16 4月, 2011 1 次提交
  2. 31 3月, 2011 1 次提交
  3. 23 3月, 2011 6 次提交
    • V
      [net/9p]: Introduce basic flow-control for VirtIO transport. · 68da9ba4
      Venkateswararao Jujjuri (JV) 提交于
      Recent zerocopy work in the 9P VirtIO transport maps and pins
      user buffers into kernel memory for the server to work on them.
      Since the user process can initiate this kind of pinning with a simple
      read/write call, thousands of IO threads initiated by the user process can
      hog the system resources and could result into denial of service.
      
      This patch introduces flow control to avoid that extreme scenario.
      
      The ceiling limit to avoid denial of service attacks is set to relatively
      high (nr_free_pagecache_pages()/4) so that it won't interfere with
      regular usage, but can step in extreme cases to limit the total system
      hang. Since we don't have a global structure to accommodate this variable,
      I choose the virtio_chan as the home for this.
      Signed-off-by: NVenkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
      Reviewed-by: NBadari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      68da9ba4
    • V
    • V
      [net/9p] Set the condition just before waking up. · a01a9840
      Venkateswararao Jujjuri (JV) 提交于
      Given that the sprious wake-ups are common, we need to move the
      condition setting right next to the wake_up().  After setting the condition
      to req->status = REQ_STATUS_RCVD, sprious wakeups may cause the
      virtqueue back on the free list for someone else to use.
      This may result in kernel panic while relasing the pinned pages
      in p9_release_req_pages().
      
      Also rearranged the while loop in req_done() for better redability.
      Signed-off-by: NVenkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      a01a9840
    • V
      [net/9p] unconditional wake_up to proc waiting for space on VirtIO ring · 53bda3e5
      Venkateswararao Jujjuri (JV) 提交于
      Process may wait to get space on VirtIO ring to send a transaction to
      VirtFS server. Current code just does a conditional wake_up() which
      means only one process will be woken up even if multiple processes
      are waiting.
      
      This fix makes the wake_up unconditional. Hence we won't have any
      processes waiting for-ever.
      Signed-off-by: NVenkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      53bda3e5
    • 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
  4. 15 3月, 2011 10 次提交
  5. 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
  6. 20 1月, 2011 1 次提交
  7. 11 1月, 2011 1 次提交
  8. 09 12月, 2010 1 次提交
  9. 28 10月, 2010 11 次提交
  10. 21 10月, 2010 1 次提交
  11. 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
  12. 27 9月, 2010 1 次提交
  13. 24 9月, 2010 1 次提交
  14. 13 9月, 2010 1 次提交
  15. 07 9月, 2010 1 次提交