1. 11 5月, 2012 1 次提交
  2. 08 5月, 2012 1 次提交
  3. 04 5月, 2012 1 次提交
  4. 03 5月, 2012 3 次提交
    • E
      tcp: change tcp_adv_win_scale and tcp_rmem[2] · b49960a0
      Eric Dumazet 提交于
      tcp_adv_win_scale default value is 2, meaning we expect a good citizen
      skb to have skb->len / skb->truesize ratio of 75% (3/4)
      
      In 2.6 kernels we (mis)accounted for typical MSS=1460 frame :
      1536 + 64 + 256 = 1856 'estimated truesize', and 1856 * 3/4 = 1392.
      So these skbs were considered as not bloated.
      
      With recent truesize fixes, a typical MSS=1460 frame truesize is now the
      more precise :
      2048 + 256 = 2304. But 2304 * 3/4 = 1728.
      So these skb are not good citizen anymore, because 1460 < 1728
      
      (GRO can escape this problem because it build skbs with a too low
      truesize.)
      
      This also means tcp advertises a too optimistic window for a given
      allocated rcvspace : When receiving frames, sk_rmem_alloc can hit
      sk_rcvbuf limit and we call tcp_prune_queue()/tcp_collapse() too often,
      especially when application is slow to drain its receive queue or in
      case of losses (netperf is fast, scp is slow). This is a major latency
      source.
      
      We should adjust the len/truesize ratio to 50% instead of 75%
      
      This patch :
      
      1) changes tcp_adv_win_scale default to 1 instead of 2
      
      2) increase tcp_rmem[2] limit from 4MB to 6MB to take into account
      better truesize tracking and to allow autotuning tcp receive window to
      reach same value than before. Note that same amount of kernel memory is
      consumed compared to 2.6 kernels.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b49960a0
    • S
      net: l2tp: unlock socket lock before returning from l2tp_ip_sendmsg · 84768edb
      Sasha Levin 提交于
      l2tp_ip_sendmsg could return without releasing socket lock, making it all the
      way to userspace, and generating the following warning:
      
      [  130.891594] ================================================
      [  130.894569] [ BUG: lock held when returning to user space! ]
      [  130.897257] 3.4.0-rc5-next-20120501-sasha #104 Tainted: G        W
      [  130.900336] ------------------------------------------------
      [  130.902996] trinity/8384 is leaving the kernel with locks still held!
      [  130.906106] 1 lock held by trinity/8384:
      [  130.907924]  #0:  (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550
      
      Introduced by commit 2f16270f ("l2tp: Fix locking in l2tp_ip.c").
      Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84768edb
    • N
      drop_monitor: prevent init path from scheduling on the wrong cpu · 4fdcfa12
      Neil Horman 提交于
      I just noticed after some recent updates, that the init path for the drop
      monitor protocol has a minor error.  drop monitor maintains a per cpu structure,
      that gets initalized from a single cpu.  Normally this is fine, as the protocol
      isn't in use yet, but I recently made a change that causes a failed skb
      allocation to reschedule itself .  Given the current code, the implication is
      that this workqueue reschedule will take place on the wrong cpu.  If drop
      monitor is used early during the boot process, its possible that two cpus will
      access a single per-cpu structure in parallel, possibly leading to data
      corruption.
      
      This patch fixes the situation, by storing the cpu number that a given instance
      of this per-cpu data should be accessed from.  In the case of a need for a
      reschedule, the cpu stored in the struct is assigned the rescheule, rather than
      the currently executing cpu
      
      Tested successfully by myself.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: David Miller <davem@davemloft.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4fdcfa12
  5. 02 5月, 2012 1 次提交
  6. 01 5月, 2012 2 次提交
  7. 30 4月, 2012 5 次提交
  8. 28 4月, 2012 7 次提交
  9. 26 4月, 2012 6 次提交
  10. 25 4月, 2012 3 次提交
    • J
      ipvs: fix crash in ip_vs_control_net_cleanup on unload · 8f9b9a2f
      Julian Anastasov 提交于
      	commit 14e40546 (2.6.39)
      ("Add __ip_vs_control_{init,cleanup}_sysctl()")
      introduced regression due to wrong __net_init for
      __ip_vs_control_cleanup_sysctl. This leads to crash when
      the ip_vs module is unloaded.
      
      	Fix it by changing __net_init to __net_exit for
      the function that is already renamed to ip_vs_control_net_cleanup_sysctl.
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NHans Schillstrom <hans@schillstrom.com>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      8f9b9a2f
    • S
      ipvs: Verify that IP_VS protocol has been registered · 7118c07a
      Sasha Levin 提交于
      The registration of a protocol might fail, there were no checks
      and all registrations were assumed to be correct. This lead to
      NULL ptr dereferences when apps tried registering.
      
      For example:
      
      [ 1293.226051] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
      [ 1293.227038] IP: [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
      [ 1293.227038] PGD 391de067 PUD 6c20b067 PMD 0
      [ 1293.227038] Oops: 0000 [#1] PREEMPT SMP
      [ 1293.227038] CPU 1
      [ 1293.227038] Pid: 19609, comm: trinity Tainted: G        W    3.4.0-rc1-next-20120405-sasha-dirty #57
      [ 1293.227038] RIP: 0010:[<ffffffff822aacb0>]  [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
      [ 1293.227038] RSP: 0018:ffff880038c1dd18  EFLAGS: 00010286
      [ 1293.227038] RAX: ffffffffffffffc0 RBX: 0000000000001500 RCX: 0000000000010000
      [ 1293.227038] RDX: 0000000000000000 RSI: ffff88003a2d5888 RDI: 0000000000000282
      [ 1293.227038] RBP: ffff880038c1dd48 R08: 0000000000000000 R09: 0000000000000000
      [ 1293.227038] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003a2d5668
      [ 1293.227038] R13: ffff88003a2d5988 R14: ffff8800696a8ff8 R15: 0000000000000000
      [ 1293.227038] FS:  00007f01930d9700(0000) GS:ffff88007ce00000(0000) knlGS:0000000000000000
      [ 1293.227038] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [ 1293.227038] CR2: 0000000000000018 CR3: 0000000065dfc000 CR4: 00000000000406e0
      [ 1293.227038] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 1293.227038] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [ 1293.227038] Process trinity (pid: 19609, threadinfo ffff880038c1c000, task ffff88002dc73000)
      [ 1293.227038] Stack:
      [ 1293.227038]  ffff880038c1dd48 00000000fffffff4 ffff8800696aada0 ffff8800694f5580
      [ 1293.227038]  ffffffff8369f1e0 0000000000001500 ffff880038c1dd98 ffffffff822a716b
      [ 1293.227038]  0000000000000000 ffff8800696a8ff8 0000000000000015 ffff8800694f5580
      [ 1293.227038] Call Trace:
      [ 1293.227038]  [<ffffffff822a716b>] ip_vs_app_inc_new+0xdb/0x180
      [ 1293.227038]  [<ffffffff822a7258>] register_ip_vs_app_inc+0x48/0x70
      [ 1293.227038]  [<ffffffff822b2fea>] __ip_vs_ftp_init+0xba/0x140
      [ 1293.227038]  [<ffffffff821c9060>] ops_init+0x80/0x90
      [ 1293.227038]  [<ffffffff821c90cb>] setup_net+0x5b/0xe0
      [ 1293.227038]  [<ffffffff821c9416>] copy_net_ns+0x76/0x100
      [ 1293.227038]  [<ffffffff810dc92b>] create_new_namespaces+0xfb/0x190
      [ 1293.227038]  [<ffffffff810dca21>] unshare_nsproxy_namespaces+0x61/0x80
      [ 1293.227038]  [<ffffffff810afd1f>] sys_unshare+0xff/0x290
      [ 1293.227038]  [<ffffffff8187622e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      [ 1293.227038]  [<ffffffff82665539>] system_call_fastpath+0x16/0x1b
      [ 1293.227038] Code: 89 c7 e8 34 91 3b 00 89 de 66 c1 ee 04 31 de 83 e6 0f 48 83 c6 22 48 c1 e6 04 4a 8b 14 26 49 8d 34 34 48 8d 42 c0 48 39 d6 74 13 <66> 39 58 58 74 22 48 8b 48 40 48 8d 41 c0 48 39 ce 75 ed 49 8d
      [ 1293.227038] RIP  [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
      [ 1293.227038]  RSP <ffff880038c1dd18>
      [ 1293.227038] CR2: 0000000000000018
      [ 1293.379284] ---[ end trace 364ab40c7011a009 ]---
      [ 1293.381182] Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
      Acked-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      7118c07a
    • E
      mac80211: call ieee80211_mgd_stop() on interface stop · afa762f6
      Eliad Peller 提交于
      ieee80211_mgd_teardown() is called on netdev removal, which
      occurs after the vif was already removed from the low-level
      driver, resulting in the following warning:
      
      [ 4809.014734] ------------[ cut here ]------------
      [ 4809.019861] WARNING: at net/mac80211/driver-ops.h:12 ieee80211_bss_info_change_notify+0x200/0x2c8 [mac80211]()
      [ 4809.030388] wlan0:  Failed check-sdata-in-driver check, flags: 0x4
      [ 4809.036862] Modules linked in: wlcore_sdio(-) wl12xx wlcore mac80211 cfg80211 [last unloaded: cfg80211]
      [ 4809.046849] [<c001bd4c>] (unwind_backtrace+0x0/0x12c)
      [ 4809.055937] [<c047cf1c>] (dump_stack+0x20/0x24)
      [ 4809.065385] [<c003e334>] (warn_slowpath_common+0x5c/0x74)
      [ 4809.075589] [<c003e408>] (warn_slowpath_fmt+0x40/0x48)
      [ 4809.088291] [<bf033630>] (ieee80211_bss_info_change_notify+0x200/0x2c8 [mac80211])
      [ 4809.102844] [<bf067f84>] (ieee80211_destroy_auth_data+0x80/0xa4 [mac80211])
      [ 4809.116276] [<bf068004>] (ieee80211_mgd_teardown+0x5c/0x74 [mac80211])
      [ 4809.129331] [<bf043f18>] (ieee80211_teardown_sdata+0xb0/0xd8 [mac80211])
      [ 4809.141595] [<c03b5e58>] (rollback_registered_many+0x228/0x2f0)
      [ 4809.153056] [<c03b5f48>] (unregister_netdevice_many+0x28/0x50)
      [ 4809.165696] [<bf041ea8>] (ieee80211_remove_interfaces+0xb4/0xdc [mac80211])
      [ 4809.179151] [<bf032174>] (ieee80211_unregister_hw+0x50/0xf0 [mac80211])
      [ 4809.191043] [<bf0bebb4>] (wlcore_remove+0x5c/0x7c [wlcore])
      [ 4809.201491] [<c02c6918>] (platform_drv_remove+0x24/0x28)
      [ 4809.212029] [<c02c4d50>] (__device_release_driver+0x8c/0xcc)
      [ 4809.222738] [<c02c4e84>] (device_release_driver+0x30/0x3c)
      [ 4809.233099] [<c02c4258>] (bus_remove_device+0x10c/0x128)
      [ 4809.242620] [<c02c26f8>] (device_del+0x11c/0x17c)
      [ 4809.252150] [<c02c6de0>] (platform_device_del+0x28/0x68)
      [ 4809.263051] [<bf0df49c>] (wl1271_remove+0x3c/0x50 [wlcore_sdio])
      [ 4809.273590] [<c03806b0>] (sdio_bus_remove+0x48/0xf8)
      [ 4809.283754] [<c02c4d50>] (__device_release_driver+0x8c/0xcc)
      [ 4809.293729] [<c02c4e2c>] (driver_detach+0x9c/0xc4)
      [ 4809.303163] [<c02c3d7c>] (bus_remove_driver+0xc4/0xf4)
      [ 4809.312973] [<c02c5a98>] (driver_unregister+0x70/0x7c)
      [ 4809.323220] [<c03809c4>] (sdio_unregister_driver+0x24/0x2c)
      [ 4809.334213] [<bf0df458>] (wl1271_exit+0x14/0x1c [wlcore_sdio])
      [ 4809.344930] [<c009b1a4>] (sys_delete_module+0x228/0x2a8)
      [ 4809.354734] ---[ end trace 515290ccf5feb522 ]---
      
      Rename ieee80211_mgd_teardown() to ieee80211_mgd_stop(),
      and call it on ieee80211_do_stop().
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      afa762f6
  11. 24 4月, 2012 2 次提交
  12. 23 4月, 2012 1 次提交
  13. 22 4月, 2012 1 次提交
  14. 20 4月, 2012 1 次提交
    • E
      net ax25: Reorder ax25_exit to remove races. · 3adadc08
      Eric W. Biederman 提交于
      While reviewing the sysctl code in ax25 I spotted races in ax25_exit
      where it is possible to receive notifications and packets after already
      freeing up some of the data structures needed to process those
      notifications and updates.
      
      Call unregister_netdevice_notifier early so that the rest of the cleanup
      code does not need to deal with network devices.  This takes advantage
      of my recent enhancement to unregister_netdevice_notifier to send
      unregister notifications of all network devices that are current
      registered.
      
      Move the unregistration for packet types, socket types and protocol
      types before we cleanup any of the ax25 data structures to remove the
      possibilities of other races.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3adadc08
  15. 19 4月, 2012 1 次提交
    • E
      tcp: fix retransmit of partially acked frames · 22b4a4f2
      Eric Dumazet 提交于
      Alexander Beregalov reported skb_over_panic errors and provided stack
      trace.
      
      I occurs commit a21d4572 (tcp: avoid order-1 allocations on wifi and
      tx path) added a regression, when a retransmit is done after a partial
      ACK.
      
      tcp_retransmit_skb() tries to aggregate several frames if the first one
      has enough available room to hold the following ones payload. This is
      controlled by /proc/sys/net/ipv4/tcp_retrans_collapse tunable (default :
      enabled)
      
      Problem is we must make sure _pskb_trim_head() doesnt fool
      skb_availroom() when pulling some bytes from skb (this pull is done when
      receiver ACK part of the frame).
      Reported-by: NAlexander Beregalov <a.beregalov@gmail.com>
      Cc: Marc MERLIN <marc@merlins.org>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22b4a4f2
  16. 18 4月, 2012 4 次提交