1. 12 6月, 2014 2 次提交
    • D
      net/core: Add VF link state control policy · c5b46160
      Doug Ledford 提交于
      Commit 1d8faf48 (net/core: Add VF link state control) added VF link state
      control to the netlink VF nested structure, but failed to add a proper entry
      for the new structure into the VF policy table.  Add the missing entry so
      the table and the actual data copied into the netlink nested struct are in
      sync.
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5b46160
    • J
      sfc: PIO:Restrict to 64bit arch and use 64-bit writes. · daf37b55
      Jon Cooper 提交于
      Fixes:ee45fd92
      ("sfc: Use TX PIO for sufficiently small packets")
      
      The linux net driver uses memcpy_toio() in order to copy into
      the PIO buffers.
      Even on a 64bit machine this causes 32bit accesses to a write-
      combined memory region.
      There are hardware limitations that mean that only 64bit
      naturally aligned accesses are safe in all cases.
      Due to being write-combined memory region two 32bit accesses
      may be coalesced to form a 64bit non 64bit aligned access.
      Solution was to open-code the memory copy routines using pointers
      and to only enable PIO for x86_64 machines.
      
      Not tested on platforms other than x86_64 because this patch
      disables the PIO feature on other platforms.
      Compile-tested on x86 to ensure that works.
      
      The WARN_ON_ONCE() code in the previous version of this patch
      has been moved into the internal sfc debug driver as the
      assertion was unnecessary in the upstream kernel code.
      
      This bug fix applies to v3.13 and v3.14 stable branches.
      Signed-off-by: NShradha Shah <sshah@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      daf37b55
  2. 11 6月, 2014 6 次提交
    • W
      net: fix UDP tunnel GSO of frag_list GRO packets · 5882a07c
      Wei-Chun Chao 提交于
      This patch fixes a kernel BUG_ON in skb_segment. It is hit when
      testing two VMs on openvswitch with one VM acting as VXLAN gateway.
      
      During VXLAN packet GSO, skb_segment is called with skb->data
      pointing to inner TCP payload. skb_segment calls skb_network_protocol
      to retrieve the inner protocol. skb_network_protocol actually expects
      skb->data to point to MAC and it calls pskb_may_pull with ETH_HLEN.
      This ends up pulling in ETH_HLEN data from header tail. As a result,
      pskb_trim logic is skipped and BUG_ON is hit later.
      
      Move skb_push in front of skb_network_protocol so that skb->data
      lines up properly.
      
      kernel BUG at net/core/skbuff.c:2999!
      Call Trace:
      [<ffffffff816ac412>] tcp_gso_segment+0x122/0x410
      [<ffffffff816bc74c>] inet_gso_segment+0x13c/0x390
      [<ffffffff8164b39b>] skb_mac_gso_segment+0x9b/0x170
      [<ffffffff816b3658>] skb_udp_tunnel_segment+0xd8/0x390
      [<ffffffff816b3c00>] udp4_ufo_fragment+0x120/0x140
      [<ffffffff816bc74c>] inet_gso_segment+0x13c/0x390
      [<ffffffff8109d742>] ? default_wake_function+0x12/0x20
      [<ffffffff8164b39b>] skb_mac_gso_segment+0x9b/0x170
      [<ffffffff8164b4d0>] __skb_gso_segment+0x60/0xc0
      [<ffffffff8164b6b3>] dev_hard_start_xmit+0x183/0x550
      [<ffffffff8166c91e>] sch_direct_xmit+0xfe/0x1d0
      [<ffffffff8164bc94>] __dev_queue_xmit+0x214/0x4f0
      [<ffffffff8164bf90>] dev_queue_xmit+0x10/0x20
      [<ffffffff81687edb>] ip_finish_output+0x66b/0x890
      [<ffffffff81688a58>] ip_output+0x58/0x90
      [<ffffffff816c628f>] ? fib_table_lookup+0x29f/0x350
      [<ffffffff816881c9>] ip_local_out_sk+0x39/0x50
      [<ffffffff816cbfad>] iptunnel_xmit+0x10d/0x130
      [<ffffffffa0212200>] vxlan_xmit_skb+0x1d0/0x330 [vxlan]
      [<ffffffffa02a3919>] vxlan_tnl_send+0x129/0x1a0 [openvswitch]
      [<ffffffffa02a2cd6>] ovs_vport_send+0x26/0xa0 [openvswitch]
      [<ffffffffa029931e>] do_output+0x2e/0x50 [openvswitch]
      Signed-off-by: NWei-Chun Chao <weichunc@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5882a07c
    • H
      net: ipv6: Fixed up ipsec packet be re-routing issue · f6c20c59
      huizhang 提交于
      Bug report on https://bugzilla.kernel.org/show_bug.cgi?id=75781
      
      When a local output ipsec packet match the mangle table rule,
      and be set mark value, the packet will be route again in
      route_me_harder -> _session_decoder6
      
      In this case, the nhoff in CB of skb was still the default
      value 0. So the protocal match can't success and the packet can't match
      correct SA rule,and then the packet be send out in plaintext.
      
      To fixed up the issue. The CB->nhoff must be set.
      Signed-off-by: NHui Zhang <huizhang@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6c20c59
    • D
      ip_tunnel: fix i_key matching in ip_tunnel_find · 5ce54af1
      Dmitry Popov 提交于
      Some tunnels (though only vti as for now) can use i_key just for internal use:
      for example vti uses it for fwmark'ing incoming packets. So raw i_key value
      shouldn't be treated as a distinguisher for them. ip_tunnel_key_match exists for
      cases when we want to compare two ip_tunnel_parms' i_keys.
      
      Example bug:
      ip link add type vti ikey 1 local 1.0.0.1 remote 2.0.0.2
      ip link add type vti ikey 2 local 1.0.0.1 remote 2.0.0.2
      spawned two tunnels, although it doesn't make sense.
      Signed-off-by: NDmitry Popov <ixaphire@qrator.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5ce54af1
    • D
      ip_vti: Fix 'ip tunnel add' with 'key' parameters · 7c8e6b9c
      Dmitry Popov 提交于
      ip tunnel add remote 10.2.2.1 local 10.2.2.2 mode vti ikey 1 okey 2
      translates to p->iflags = VTI_ISVTI|GRE_KEY and p->i_key = 1, but GRE_KEY !=
      TUNNEL_KEY, so ip_tunnel_ioctl would set i_key to 0 (same story with o_key)
      making us unable to create vti tunnels with [io]key via ip tunnel.
      
      We cannot simply translate GRE_KEY to TUNNEL_KEY (as GRE module does) because
      vti_tunnels with same local/remote addresses but different ikeys will be treated
      as different then. So, imo the best option here is to move p->i_flags & *_KEY
      check for vti tunnels from ip_tunnel.c to ip_vti.c and to think about [io]_mark
      field for ip_tunnel_parm in the future.
      Signed-off-by: NDmitry Popov <ixaphire@qrator.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c8e6b9c
    • M
      dns_resolver: assure that dns_query() result is null-terminated · 84a7c0b1
      Manuel Schölling 提交于
      dns_query() credulously assumes that keys are null-terminated and
      returns a copy of a memory block that is off by one.
      Signed-off-by: NManuel Schölling <manuel.schoelling@gmx.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84a7c0b1
    • D
      ipip, sit: fix ipv4_{update_pmtu,redirect} calls · 2346829e
      Dmitry Popov 提交于
      ipv4_{update_pmtu,redirect} were called with tunnel's ifindex (t->dev is a
      tunnel netdevice). It caused wrong route lookup and failure of pmtu update or
      redirect. We should use the same ifindex that we use in ip_route_output_* in
      *tunnel_xmit code. It is t->parms.link .
      Signed-off-by: NDmitry Popov <ixaphire@qrator.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2346829e
  3. 09 6月, 2014 1 次提交
  4. 07 6月, 2014 2 次提交
  5. 06 6月, 2014 8 次提交
  6. 05 6月, 2014 1 次提交
  7. 04 6月, 2014 7 次提交
  8. 03 6月, 2014 13 次提交