1. 18 3月, 2014 6 次提交
  2. 14 3月, 2014 1 次提交
  3. 13 3月, 2014 2 次提交
  4. 12 3月, 2014 6 次提交
  5. 11 3月, 2014 1 次提交
  6. 28 2月, 2014 2 次提交
  7. 27 2月, 2014 2 次提交
  8. 25 2月, 2014 3 次提交
  9. 22 2月, 2014 1 次提交
  10. 19 2月, 2014 1 次提交
  11. 17 2月, 2014 3 次提交
  12. 15 2月, 2014 1 次提交
  13. 14 2月, 2014 3 次提交
  14. 12 2月, 2014 2 次提交
  15. 10 2月, 2014 2 次提交
  16. 07 2月, 2014 2 次提交
    • E
      net: use __GFP_NORETRY for high order allocations · ed98df33
      Eric Dumazet 提交于
      sock_alloc_send_pskb() & sk_page_frag_refill()
      have a loop trying high order allocations to prepare
      skb with low number of fragments as this increases performance.
      
      Problem is that under memory pressure/fragmentation, this can
      trigger OOM while the intent was only to try the high order
      allocations, then fallback to order-0 allocations.
      
      We had various reports from unexpected regressions.
      
      According to David, setting __GFP_NORETRY should be fine,
      as the asynchronous compaction is still enabled, and this
      will prevent OOM from kicking as in :
      
      CFSClientEventm invoked oom-killer: gfp_mask=0x42d0, order=3, oom_adj=0,
      oom_score_adj=0, oom_score_badness=2 (enabled),memcg_scoring=disabled
      CFSClientEventm
      
      Call Trace:
       [<ffffffff8043766c>] dump_header+0xe1/0x23e
       [<ffffffff80437a02>] oom_kill_process+0x6a/0x323
       [<ffffffff80438443>] out_of_memory+0x4b3/0x50d
       [<ffffffff8043a4a6>] __alloc_pages_may_oom+0xa2/0xc7
       [<ffffffff80236f42>] __alloc_pages_nodemask+0x1002/0x17f0
       [<ffffffff8024bd23>] alloc_pages_current+0x103/0x2b0
       [<ffffffff8028567f>] sk_page_frag_refill+0x8f/0x160
       [<ffffffff80295fa0>] tcp_sendmsg+0x560/0xee0
       [<ffffffff802a5037>] inet_sendmsg+0x67/0x100
       [<ffffffff80283c9c>] __sock_sendmsg_nosec+0x6c/0x90
       [<ffffffff80283e85>] sock_sendmsg+0xc5/0xf0
       [<ffffffff802847b6>] __sys_sendmsg+0x136/0x430
       [<ffffffff80284ec8>] sys_sendmsg+0x88/0x110
       [<ffffffff80711472>] system_call_fastpath+0x16/0x1b
      Out of Memory: Kill process 2856 (bash) score 9999 or sacrifice child
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ed98df33
    • S
      netpoll: fix netconsole IPv6 setup · 00fe11b3
      Sabrina Dubroca 提交于
      Currently, to make netconsole start over IPv6, the source address
      needs to be specified. Without a source address, netpoll_parse_options
      assumes we're setting up over IPv4 and the destination IPv6 address is
      rejected.
      
      Check if the IP version has been forced by a source address before
      checking for a version mismatch when parsing the destination address.
      Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
      Acked-by: NCong Wang <cwang@twopensource.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      00fe11b3
  17. 05 2月, 2014 1 次提交
    • F
      rtnetlink: fix oops in rtnl_link_get_slave_info_data_size · 6049f253
      Fernando Luis Vazquez Cao 提交于
      We should check whether rtnetlink link operations
      are defined before calling get_slave_size().
      
      Without this, the following oops can occur when
      adding a tap device to OVS.
      
      [   87.839553] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
      [   87.839595] IP: [<ffffffff813d47c0>] if_nlmsg_size+0xf0/0x220
      [...]
      [   87.840651] Call Trace:
      [   87.840664]  [<ffffffff813d694b>] ? rtmsg_ifinfo+0x2b/0x100
      [   87.840688]  [<ffffffff813c8340>] ? __netdev_adjacent_dev_insert+0x150/0x1a0
      [   87.840718]  [<ffffffff813d6a50>] ? rtnetlink_event+0x30/0x40
      [   87.840742]  [<ffffffff814b4144>] ? notifier_call_chain+0x44/0x70
      [   87.840768]  [<ffffffff813c8946>] ? __netdev_upper_dev_link+0x3c6/0x3f0
      [   87.840798]  [<ffffffffa0678d6c>] ? netdev_create+0xcc/0x160 [openvswitch]
      [   87.840828]  [<ffffffffa06781ea>] ? ovs_vport_add+0x4a/0xd0 [openvswitch]
      [   87.840857]  [<ffffffffa0670139>] ? new_vport+0x9/0x50 [openvswitch]
      [   87.840884]  [<ffffffffa067279e>] ? ovs_vport_cmd_new+0x11e/0x210 [openvswitch]
      [   87.840915]  [<ffffffff813f3efa>] ? genl_family_rcv_msg+0x19a/0x360
      [   87.840941]  [<ffffffff813f40c0>] ? genl_family_rcv_msg+0x360/0x360
      [   87.840967]  [<ffffffff813f4139>] ? genl_rcv_msg+0x79/0xc0
      [   87.840991]  [<ffffffff813b6cf9>] ? __kmalloc_reserve.isra.25+0x29/0x80
      [   87.841018]  [<ffffffff813f2389>] ? netlink_rcv_skb+0xa9/0xc0
      [   87.841042]  [<ffffffff813f27cf>] ? genl_rcv+0x1f/0x30
      [   87.841064]  [<ffffffff813f1988>] ? netlink_unicast+0xe8/0x1e0
      [   87.841088]  [<ffffffff813f1d9a>] ? netlink_sendmsg+0x31a/0x750
      [   87.841113]  [<ffffffff813aee96>] ? sock_sendmsg+0x86/0xc0
      [   87.841136]  [<ffffffff813c960d>] ? __netdev_update_features+0x4d/0x200
      [   87.841163]  [<ffffffff813ca94e>] ? ethtool_get_value+0x2e/0x50
      [   87.841188]  [<ffffffff813af269>] ? ___sys_sendmsg+0x359/0x370
      [   87.841212]  [<ffffffff813da686>] ? dev_ioctl+0x1a6/0x5c0
      [   87.841236]  [<ffffffff8109c210>] ? autoremove_wake_function+0x30/0x30
      [   87.841264]  [<ffffffff813ac59d>] ? sock_do_ioctl+0x3d/0x50
      [   87.841288]  [<ffffffff813aca68>] ? sock_ioctl+0x1e8/0x2c0
      [   87.841312]  [<ffffffff811934bf>] ? do_vfs_ioctl+0x2cf/0x4b0
      [   87.841335]  [<ffffffff813afeb9>] ? __sys_sendmsg+0x39/0x70
      [   87.841362]  [<ffffffff814b86f9>] ? system_call_fastpath+0x16/0x1b
      [   87.841386] Code: c0 74 10 48 89 ef ff d0 83 c0 07 83 e0 fc 48 98 49 01 c7 48 89 ef e8 d0 d6 fe ff 48 85 c0 0f 84 df 00 00 00 48 8b 90 08 07 00 00 <48> 8b 8a a8 00 00 00 31 d2 48 85 c9 74 0c 48 89 ee 48 89 c7 ff
      [   87.841529] RIP  [<ffffffff813d47c0>] if_nlmsg_size+0xf0/0x220
      [   87.841555]  RSP <ffff880221aa5950>
      [   87.841569] CR2: 00000000000000a8
      [   87.851442] ---[ end trace e42ab217691b4fc2 ]---
      Signed-off-by: NFernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
      Acked-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6049f253
  18. 29 1月, 2014 1 次提交