1. 12 3月, 2014 3 次提交
  2. 28 2月, 2014 1 次提交
  3. 22 2月, 2014 1 次提交
  4. 17 2月, 2014 3 次提交
  5. 14 2月, 2014 2 次提交
  6. 10 2月, 2014 2 次提交
  7. 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
  8. 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
  9. 29 1月, 2014 1 次提交
  10. 27 1月, 2014 1 次提交
  11. 24 1月, 2014 2 次提交
    • J
      rtnetlink: remove check for fill_slave_info in rtnl_have_link_slave_info · 813f020c
      Jiri Pirko 提交于
      This check is not needed because the same check is done before
      fill_slave_info is used in rtnl_link_slave_info_fill.
      Also, by removing this check, kernel will fillup IFLA_INFO_SLAVE_KIND
      even for slaves of masters which does not implement fill_slave_info.
      Signed-off-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      813f020c
    • V
      net: Correctly sync addresses from multiple sources to single device · 6ef7b8a2
      Vlad Yasevich 提交于
      When we have multiple devices attempting to sync the same address
      to a single destination, each device should be permitted to sync
      it once.  To accomplish this, pass the 'sync_cnt' of the source
      address when adding the addresss to the lower device.  'sync_cnt'
      tracks how many time a given address has been succefully synced.
      This way, we know that if the 'sync_cnt' passed in is 0, we should
      sync this address.
      
      Also, turn 'synced' member back into the counter as was originally
      done in
         commit 4543fbef.
         net: count hw_addr syncs so that unsync works properly.
      It tracks how many time a given address has been added via a
      'sync' operation.  For every successfull 'sync' the counter is
      incremented, and for ever 'unsync', the counter is decremented.
      This makes sure that the address will be properly removed from
      the the lower device when all the upper devices have removed it.
      Reported-by: NAndrey Dmitrov <andrey.dmitrov@oktetlabs.ru>
      CC: Andrey Dmitrov <andrey.dmitrov@oktetlabs.ru>
      CC: Alexandra N. Kossovsky <Alexandra.Kossovsky@oktetlabs.ru>
      CC: Konstantin Ushakov <Konstantin.Ushakov@oktetlabs.ru>
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6ef7b8a2
  12. 23 1月, 2014 5 次提交
  13. 22 1月, 2014 5 次提交
  14. 20 1月, 2014 2 次提交
  15. 19 1月, 2014 1 次提交
    • M
      net: introduce SO_BPF_EXTENSIONS · ea02f941
      Michal Sekletar 提交于
      For user space packet capturing libraries such as libpcap, there's
      currently only one way to check which BPF extensions are supported
      by the kernel, that is, commit aa1113d9 ("net: filter: return
      -EINVAL if BPF_S_ANC* operation is not supported"). For querying all
      extensions at once this might be rather inconvenient.
      
      Therefore, this patch introduces a new option which can be used as
      an argument for getsockopt(), and allows one to obtain information
      about which BPF extensions are supported by the current kernel.
      
      As David Miller suggests, we do not need to define any bits right
      now and status quo can just return 0 in order to state that this
      versions supports SKF_AD_PROTOCOL up to SKF_AD_PAY_OFFSET. Later
      additions to BPF extensions need to add their bits to the
      bpf_tell_extensions() function, as documented in the comment.
      Signed-off-by: NMichal Sekletar <msekleta@redhat.com>
      Cc: David Miller <davem@davemloft.net>
      Reviewed-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ea02f941
  16. 18 1月, 2014 1 次提交
  17. 17 1月, 2014 4 次提交
  18. 16 1月, 2014 3 次提交