1. 18 11月, 2015 1 次提交
    • V
      vlan: Do not put vlan headers back on bridge and macvlan ports · 28f9ee22
      Vlad Yasevich 提交于
      When a vlan is configured with REORDER_HEADER set to 0, the vlan
      header is put back into the packet and makes it appear that
      the vlan header is still there even after it's been processed.
      This posses a problem for bridge and macvlan ports.  The packets
      passed to those device may be forwarded and at the time of the
      forward, vlan headers end up being unexpectedly present.
      
      With the patch, we make sure that we do not put the vlan header
      back (when REORDER_HEADER is 0) if a bridge or macvlan has
      been configured on top of the vlan device.
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      28f9ee22
  2. 17 11月, 2015 2 次提交
    • D
      net: switchdev: fix return code of fdb_dump stub · 24cb7055
      Dragos Tatulea 提交于
      rtnl_fdb_dump always expects an index to be returned by the ndo_fdb_dump op,
      but when CONFIG_NET_SWITCHDEV is off, it returns an error.
      
      Fix that by returning the given unmodified idx.
      
      A similar fix was 0890cf6c ("switchdev: fix return value of
      switchdev_port_fdb_dump in case of error") but for the CONFIG_NET_SWITCHDEV=y
      case.
      
      Fixes: 45d4122c ("switchdev: add support for fdb add/del/dump via switchdev_port_obj ops.")
      Signed-off-by: NDragos Tatulea <dragos@endocode.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      24cb7055
    • J
      ip_tunnel: disable preemption when updating per-cpu tstats · b4fe85f9
      Jason A. Donenfeld 提交于
      Drivers like vxlan use the recently introduced
      udp_tunnel_xmit_skb/udp_tunnel6_xmit_skb APIs. udp_tunnel6_xmit_skb
      makes use of ip6tunnel_xmit, and ip6tunnel_xmit, after sending the
      packet, updates the struct stats using the usual
      u64_stats_update_begin/end calls on this_cpu_ptr(dev->tstats).
      udp_tunnel_xmit_skb makes use of iptunnel_xmit, which doesn't touch
      tstats, so drivers like vxlan, immediately after, call
      iptunnel_xmit_stats, which does the same thing - calls
      u64_stats_update_begin/end on this_cpu_ptr(dev->tstats).
      
      While vxlan is probably fine (I don't know?), calling a similar function
      from, say, an unbound workqueue, on a fully preemptable kernel causes
      real issues:
      
      [  188.434537] BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u8:0/6
      [  188.435579] caller is debug_smp_processor_id+0x17/0x20
      [  188.435583] CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.6 #2
      [  188.435607] Call Trace:
      [  188.435611]  [<ffffffff8234e936>] dump_stack+0x4f/0x7b
      [  188.435615]  [<ffffffff81915f3d>] check_preemption_disabled+0x19d/0x1c0
      [  188.435619]  [<ffffffff81915f77>] debug_smp_processor_id+0x17/0x20
      
      The solution would be to protect the whole
      this_cpu_ptr(dev->tstats)/u64_stats_update_begin/end blocks with
      disabling preemption and then reenabling it.
      Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4fe85f9
  3. 16 11月, 2015 3 次提交
  4. 11 11月, 2015 3 次提交
  5. 10 11月, 2015 6 次提交
  6. 09 11月, 2015 1 次提交
  7. 08 11月, 2015 2 次提交
  8. 07 11月, 2015 22 次提交