1. 07 5月, 2016 1 次提交
  2. 22 3月, 2016 1 次提交
  3. 21 3月, 2016 1 次提交
  4. 14 3月, 2016 1 次提交
    • A
      gro: Defer clearing of flush bit in tunnel paths · c194cf93
      Alexander Duyck 提交于
      This patch updates the GRO handlers for GRE, VXLAN, GENEVE, and FOU so that
      we do not clear the flush bit until after we have called the next level GRO
      handler.  Previously this was being cleared before parsing through the list
      of frames, however this resulted in several paths where either the bit
      needed to be reset but wasn't as in the case of FOU, or cases where it was
      being set as in GENEVE.  By just deferring the clearing of the bit until
      after the next level protocol has been parsed we can avoid any unnecessary
      bit twiddling and avoid bugs.
      Signed-off-by: NAlexander Duyck <aduyck@mirantis.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c194cf93
  5. 12 3月, 2016 2 次提交
  6. 09 3月, 2016 2 次提交
  7. 05 3月, 2016 1 次提交
  8. 04 3月, 2016 1 次提交
  9. 27 2月, 2016 1 次提交
  10. 26 2月, 2016 5 次提交
  11. 22 2月, 2016 1 次提交
  12. 19 2月, 2016 5 次提交
  13. 18 2月, 2016 7 次提交
  14. 17 2月, 2016 2 次提交
  15. 12 2月, 2016 2 次提交
  16. 11 2月, 2016 1 次提交
  17. 10 2月, 2016 2 次提交
    • D
      vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices · 7e059158
      David Wragg 提交于
      Prior to 4.3, openvswitch tunnel vports (vxlan, gre and geneve) could
      transmit vxlan packets of any size, constrained only by the ability to
      send out the resulting packets.  4.3 introduced netdevs corresponding
      to tunnel vports.  These netdevs have an MTU, which limits the size of
      a packet that can be successfully encapsulated.  The default MTU
      values are low (1500 or less), which is awkwardly small in the context
      of physical networks supporting jumbo frames, and leads to a
      conspicuous change in behaviour for userspace.
      
      Instead, set the MTU on openvswitch-created netdevs to be the relevant
      maximum (i.e. the maximum IP packet size minus any relevant overhead),
      effectively restoring the behaviour prior to 4.3.
      Signed-off-by: NDavid Wragg <david@weave.works>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e059158
    • D
      vxlan: Relax MTU constraints · 72564b59
      David Wragg 提交于
      Allow the MTU of vxlan devices without an underlying device to be set
      to larger values (up to a maximum based on IP packet limits and vxlan
      overhead).
      
      Previously, their MTUs could not be set to higher than the
      conventional ethernet value of 1500.  This is a very arbitrary value
      in the context of vxlan, and prevented vxlan devices from being able
      to take advantage of jumbo frames etc.
      
      The default MTU remains 1500, for compatibility.
      Signed-off-by: NDavid Wragg <david@weave.works>
      Acked-by: NRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      72564b59
  18. 08 2月, 2016 3 次提交
  19. 30 1月, 2016 1 次提交
    • L
      vxlan: fix a out of bounds access in __vxlan_find_mac · 7256eac1
      Li RongQing 提交于
      The size of all_zeros_mac is 6 byte, but eth_hash() will access the
      8 byte, and KASan reported the below bug:
      
      [ 8596.479031] BUG: KASan: out of bounds access in __vxlan_find_mac+0x24/0x100 at addr ffffffff841514c0
      [ 8596.487647] Read of size 8 by task ip/52820
      [ 8596.490818] Address belongs to variable all_zeros_mac+0x0/0x40
      [ 8596.496051] CPU: 0 PID: 52820 Comm: ip Tainted: G WC 4.1.15 #1
      [ 8596.503520] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 02/10/2014
      [ 8596.509365] ffffffff841514c0 ffff88007450f0b8 ffffffff822fa5e1 0000000000000032
      [ 8596.516112] ffff88007450f150 ffff88007450f138 ffffffff812dd58c ffff88007450f1d8
      [ 8596.522856] ffffffff81113b80 0000000000000282 0000000000000001 ffffffff8101ee4d
      [ 8596.529599] Call Trace:
      [ 8596.530858] [<ffffffff822fa5e1>] dump_stack+0x4f/0x7b
      [ 8596.535080] [<ffffffff812dd58c>] kasan_report_error+0x3bc/0x3f0
      [ 8596.540258] [<ffffffff81113b80>] ? __lock_acquire+0x90/0x2140
      [ 8596.545245] [<ffffffff8101ee4d>] ? save_stack_trace+0x2d/0x80
      [ 8596.550234] [<ffffffff812dda70>] kasan_report+0x40/0x50
      [ 8596.554647] [<ffffffff81b211e4>] ? __vxlan_find_mac+0x24/0x100
      [ 8596.559729] [<ffffffff812dc399>] __asan_load8+0x69/0xa0
      [ 8596.564141] [<ffffffff81b211e4>] __vxlan_find_mac+0x24/0x100
      [ 8596.569033] [<ffffffff81b2683d>] vxlan_fdb_create+0x9d/0x570
      
      it can be fixed by enlarging the all_zeros_mac to 8 byte, although it is
      harmless; eth_hash() will be called in other place with the memory which
      is larger and equal to 8 byte.
      Signed-off-by: NLi RongQing <roy.qing.li@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7256eac1