1. 23 3月, 2011 3 次提交
    • 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
  2. 22 3月, 2011 8 次提交
    • S
      IPVS: Use global mutex in ip_vs_app.c · 736561a0
      Simon Horman 提交于
      As part of the work to make IPVS network namespace aware
      __ip_vs_app_mutex was replaced by a per-namespace lock,
      ipvs->app_mutex. ipvs->app_key is also supplied for debugging purposes.
      
      Unfortunately this implementation results in ipvs->app_key residing
      in non-static storage which at the very least causes a lockdep warning.
      
      This patch takes the rather heavy-handed approach of reinstating
      __ip_vs_app_mutex which will cover access to the ipvs->list_head
      of all network namespaces.
      
      [   12.610000] IPVS: Creating netns size=2456 id=0
      [   12.630000] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
      [   12.640000] BUG: key ffff880003bbf1a0 not in .data!
      [   12.640000] ------------[ cut here ]------------
      [   12.640000] WARNING: at kernel/lockdep.c:2701 lockdep_init_map+0x37b/0x570()
      [   12.640000] Hardware name: Bochs
      [   12.640000] Pid: 1, comm: swapper Tainted: G        W 2.6.38-kexec-06330-g69b7efe-dirty #122
      [   12.650000] Call Trace:
      [   12.650000]  [<ffffffff8102e685>] warn_slowpath_common+0x75/0xb0
      [   12.650000]  [<ffffffff8102e6d5>] warn_slowpath_null+0x15/0x20
      [   12.650000]  [<ffffffff8105967b>] lockdep_init_map+0x37b/0x570
      [   12.650000]  [<ffffffff8105829d>] ? trace_hardirqs_on+0xd/0x10
      [   12.650000]  [<ffffffff81055ad8>] debug_mutex_init+0x38/0x50
      [   12.650000]  [<ffffffff8104bc4c>] __mutex_init+0x5c/0x70
      [   12.650000]  [<ffffffff81685ee7>] __ip_vs_app_init+0x64/0x86
      [   12.660000]  [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
      [   12.660000]  [<ffffffff811b1c33>] T.620+0x43/0x170
      [   12.660000]  [<ffffffff811b1e9a>] ? register_pernet_subsys+0x1a/0x40
      [   12.660000]  [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
      [   12.660000]  [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
      [   12.660000]  [<ffffffff811b1db7>] register_pernet_operations+0x57/0xb0
      [   12.660000]  [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
      [   12.670000]  [<ffffffff811b1ea9>] register_pernet_subsys+0x29/0x40
      [   12.670000]  [<ffffffff81685f19>] ip_vs_app_init+0x10/0x12
      [   12.670000]  [<ffffffff81685a87>] ip_vs_init+0x4c/0xff
      [   12.670000]  [<ffffffff8166562c>] do_one_initcall+0x7a/0x12e
      [   12.670000]  [<ffffffff8166583e>] kernel_init+0x13e/0x1c2
      [   12.670000]  [<ffffffff8128c134>] kernel_thread_helper+0x4/0x10
      [   12.670000]  [<ffffffff8128ad40>] ? restore_args+0x0/0x30
      [   12.680000]  [<ffffffff81665700>] ? kernel_init+0x0/0x1c2
      [   12.680000]  [<ffffffff8128c130>] ? kernel_thread_helper+0x0/0x1global0
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Julian Anastasov <ja@ssi.bg>
      Cc: Hans Schillstrom <hans@schillstrom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      736561a0
    • E
      ipvs: fix a typo in __ip_vs_control_init() · f40f94fc
      Eric Dumazet 提交于
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: Julian Anastasov <ja@ssi.bg>
      Acked-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f40f94fc
    • E
      net ipv6: Fix duplicate /proc/sys/net/ipv6/neigh directory entries. · 9d2a8fa9
      Eric W. Biederman 提交于
      When I was fixing issues with unregisgtering tables under /proc/sys/net/ipv6/neigh
      by adding a mount point it appears I missed a critical ordering issue, in the
      ipv6 initialization.  I had not realized that ipv6_sysctl_register is called
      at the very end of the ipv6 initialization and in particular after we call
      neigh_sysctl_register from ndisc_init.
      
      "neigh" needs to be initialized in ipv6_static_sysctl_register which is
      the first ipv6 table to initialized, and definitely before ndisc_init.
      This removes the weirdness of duplicate tables while still providing a
      "neigh" mount point which prevents races in sysctl unregistering.
      
      This was initially reported at https://bugzilla.kernel.org/show_bug.cgi?id=31232
      Reported-by: sunkan@zappa.cx
      Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9d2a8fa9
    • N
      net: fix incorrect spelling in drop monitor protocol · ac0a121d
      Neil Horman 提交于
      It was pointed out to me recently that my spelling could be better :)
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ac0a121d
    • A
      net/appletalk: fix atalk_release use after free · b20e7bbf
      Arnd Bergmann 提交于
      The BKL removal in appletalk introduced a use-after-free problem,
      where atalk_destroy_socket frees a sock, but we still release
      the socket lock on it.
      
      An easy fix is to take an extra reference on the sock and sock_put
      it when returning from atalk_release.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b20e7bbf
    • E
      ipx: fix ipx_release() · 674f2115
      Eric Dumazet 提交于
      Commit b0d0d915 (remove the BKL) added a regression, because
      sock_put() can free memory while we are going to use it later.
      
      Fix is to delay sock_put() _after_ release_sock().
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Tested-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      674f2115
    • J
      l2tp: fix possible oops on l2tp_eth module unload · 8aa525a9
      James Chapman 提交于
      A struct used in the l2tp_eth driver for registering network namespace
      ops was incorrectly marked as __net_initdata, leading to oops when
      module unloaded.
      
      BUG: unable to handle kernel paging request at ffffffffa00ec098
      IP: [<ffffffff8123dbd8>] ops_exit_list+0x7/0x4b
      PGD 142d067 PUD 1431063 PMD 195da8067 PTE 0
      Oops: 0000 [#1] SMP 
      last sysfs file: /sys/module/l2tp_eth/refcnt
      Call Trace:
       [<ffffffff8123dc94>] ? unregister_pernet_operations+0x32/0x93
       [<ffffffff8123dd20>] ? unregister_pernet_device+0x2b/0x38
       [<ffffffff81068b6e>] ? sys_delete_module+0x1b8/0x222
       [<ffffffff810c7300>] ? do_munmap+0x254/0x318
       [<ffffffff812c64e5>] ? page_fault+0x25/0x30
       [<ffffffff812c6952>] ? system_call_fastpath+0x16/0x1b
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8aa525a9
    • W
      xfrm: Fix initialize repl field of struct xfrm_state · a454f0cc
      Wei Yongjun 提交于
      Commit 'xfrm: Move IPsec replay detection functions to a separate file'
        (9fdc4883)
      introduce repl field to struct xfrm_state, and only initialize it
      under SA's netlink create path, the other path, such as pf_key,
      ipcomp/ipcomp6 etc, the repl field remaining uninitialize. So if
      the SA is created by pf_key, any input packet with SA's encryption
      algorithm will cause panic.
      
          int xfrm_input()
          {
              ...
              x->repl->advance(x, seq);
              ...
          }
      
      This patch fixed it by introduce new function __xfrm_init_state().
      
      Pid: 0, comm: swapper Not tainted 2.6.38-next+ #14 Bochs Bochs
      EIP: 0060:[<c078e5d5>] EFLAGS: 00010206 CPU: 0
      EIP is at xfrm_input+0x31c/0x4cc
      EAX: dd839c00 EBX: 00000084 ECX: 00000000 EDX: 01000000
      ESI: dd839c00 EDI: de3a0780 EBP: dec1de88 ESP: dec1de64
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process swapper (pid: 0, ti=dec1c000 task=c09c0f20 task.ti=c0992000)
      Stack:
       00000000 00000000 00000002 c0ba27c0 00100000 01000000 de3a0798 c0ba27c0
       00000033 dec1de98 c0786848 00000000 de3a0780 dec1dea4 c0786868 00000000
       dec1debc c074ee56 e1da6b8c de3a0780 c074ed44 de3a07a8 dec1decc c074ef32
      Call Trace:
       [<c0786848>] xfrm4_rcv_encap+0x22/0x27
       [<c0786868>] xfrm4_rcv+0x1b/0x1d
       [<c074ee56>] ip_local_deliver_finish+0x112/0x1b1
       [<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
       [<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
       [<c074ef77>] ip_local_deliver+0x3e/0x44
       [<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
       [<c074ec03>] ip_rcv_finish+0x30a/0x332
       [<c074e8f9>] ? ip_rcv_finish+0x0/0x332
       [<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
       [<c074f188>] ip_rcv+0x20b/0x247
       [<c074e8f9>] ? ip_rcv_finish+0x0/0x332
       [<c072797d>] __netif_receive_skb+0x373/0x399
       [<c0727bc1>] netif_receive_skb+0x4b/0x51
       [<e0817e2a>] cp_rx_poll+0x210/0x2c4 [8139cp]
       [<c072818f>] net_rx_action+0x9a/0x17d
       [<c0445b5c>] __do_softirq+0xa1/0x149
       [<c0445abb>] ? __do_softirq+0x0/0x149
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a454f0cc
  3. 20 3月, 2011 4 次提交
  4. 19 3月, 2011 5 次提交
  5. 18 3月, 2011 4 次提交
  6. 17 3月, 2011 3 次提交
  7. 16 3月, 2011 7 次提交
  8. 15 3月, 2011 6 次提交