1. 10 6月, 2016 1 次提交
    • I
      mlxsw: spectrum: Make split flow match firmware requirements · be94535f
      Ido Schimmel 提交于
      When a port is created following a split / unsplit we need to map it to
      the correct module and lane, enable it and then continue to initialize
      its various parameters such as MTU and VLAN filters.
      
      Under certain conditions, such as trying to split ports at the bottom
      row of the front panel by four, we get firmware errors.
      
      After evaluating this with the firmware team it was decided to alter the
      split / unsplit flow, so that first all the affected ports are mapped,
      then enabled and finally each is initialized separately.
      
      Fix the split / unsplit flow by first mapping and enabling all the
      affected ports. Newer firmware versions will support both flows.
      
      Fixes: 18f1e70c ("mlxsw: spectrum: Introduce port splitting")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      be94535f
  2. 09 6月, 2016 10 次提交
    • F
      qfq: don't leak skb if kzalloc fails · 9b15350f
      Florian Westphal 提交于
      When we need to create a new aggregate to enqueue the skb we call kzalloc.
      If that fails we returned ENOBUFS without freeing the skb.
      
      Spotted during code review.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9b15350f
    • S
      ip6gre: Allow live link address change · 0a46baaf
      Shweta Choudaha 提交于
      The ip6 GRE tap device should not be forced to down state to change
      the mac address and should allow live address change for tap device
      similar to ipv4 gre.
      Signed-off-by: NShweta Choudaha <schoudah@brocade.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0a46baaf
    • D
      Merge branch 'cls_u32-hwoffload-fixes' · a436d20d
      David S. Miller 提交于
      Jakub Kicinski says:
      
      ====================
      incremental cls_u32 hardware offload fixes
      
      These are incremental changes from v1 of cls_u32 fixes.
      First patch is reposted in its entirety, patch 2 is an
      incremental change from patch 2 of the original series.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a436d20d
    • J
      net: cls_u32: be more strict about skip-sw flag for knodes · 201c44bd
      Jakub Kicinski 提交于
      Return an error if user requested skip-sw and the underlaying
      hardware cannot handle tc offloads (or offloads are disabled).
      This patch fixes the knode handling.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      201c44bd
    • J
      net: cls_u32: catch all hardware offload errors · 6eef3801
      Jakub Kicinski 提交于
      Errors reported by u32_replace_hw_hnode() were not propagated.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: NSridhar Samudrala <sridhar.samudrala@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6eef3801
    • B
      sfc: report supported link speeds on SFP connections · 3497ed8c
      Bert Kenward 提交于
      7000-series SFC NICs connected with an SFP+ module currently fail to
      report any supported link speeds.
      Reported-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NBert Kenward <bkenward@solarflare.com>
      Reviewed-by: NJarod Wilson <jarod@redhat.com>
      Tested-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3497ed8c
    • E
      net_sched: add missing paddattr description · e0d194ad
      Eric Dumazet 提交于
      "make htmldocs" complains otherwise:
      
      .//net/core/gen_stats.c:65: warning: No description found for parameter 'padattr'
      .//net/core/gen_stats.c:101: warning: No description found for parameter 'padattr'
      
      Fixes: 9854518e ("sched: align nlattr properly when needed")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Acked-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e0d194ad
    • J
      ipv6: Skip XFRM lookup if dst_entry in socket cache is valid · 00bc0ef5
      Jakub Sitnicki 提交于
      At present we perform an xfrm_lookup() for each UDPv6 message we
      send. The lookup involves querying the flow cache (flow_cache_lookup)
      and, in case of a cache miss, creating an XFRM bundle.
      
      If we miss the flow cache, we can end up creating a new bundle and
      deriving the path MTU (xfrm_init_pmtu) from on an already transformed
      dst_entry, which we pass from the socket cache (sk->sk_dst_cache) down
      to xfrm_lookup(). This can happen only if we're caching the dst_entry
      in the socket, that is when we're using a connected UDP socket.
      
      To put it another way, the path MTU shrinks each time we miss the flow
      cache, which later on leads to incorrectly fragmented payload. It can
      be observed with ESPv6 in transport mode:
      
        1) Set up a transformation and lower the MTU to trigger fragmentation
          # ip xfrm policy add dir out src ::1 dst ::1 \
            tmpl src ::1 dst ::1 proto esp spi 1
          # ip xfrm state add src ::1 dst ::1 \
            proto esp spi 1 enc 'aes' 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
          # ip link set dev lo mtu 1500
      
        2) Monitor the packet flow and set up an UDP sink
          # tcpdump -ni lo -ttt &
          # socat udp6-listen:12345,fork /dev/null &
      
        3) Send a datagram that needs fragmentation with a connected socket
          # perl -e 'print "@" x 1470 | socat - udp6:[::1]:12345
          2016/06/07 18:52:52 socat[724] E read(3, 0x555bb3d5ba00, 8192): Protocol error
          00:00:00.000000 IP6 ::1 > ::1: frag (0|1448) ESP(spi=0x00000001,seq=0x2), length 1448
          00:00:00.000014 IP6 ::1 > ::1: frag (1448|32)
          00:00:00.000050 IP6 ::1 > ::1: ESP(spi=0x00000001,seq=0x3), length 1272
          (^ ICMPv6 Parameter Problem)
          00:00:00.000022 IP6 ::1 > ::1: ESP(spi=0x00000001,seq=0x5), length 136
      
        4) Compare it to a non-connected socket
          # perl -e 'print "@" x 1500' | socat - udp6-sendto:[::1]:12345
          00:00:40.535488 IP6 ::1 > ::1: frag (0|1448) ESP(spi=0x00000001,seq=0x6), length 1448
          00:00:00.000010 IP6 ::1 > ::1: frag (1448|64)
      
      What happens in step (3) is:
      
        1) when connecting the socket in __ip6_datagram_connect(), we
           perform an XFRM lookup, miss the flow cache, create an XFRM
           bundle, and cache the destination,
      
        2) afterwards, when sending the datagram, we perform an XFRM lookup,
           again, miss the flow cache (due to mismatch of flowi6_iif and
           flowi6_oif, which is an issue of its own), and recreate an XFRM
           bundle based on the cached (and already transformed) destination.
      
      To prevent the recreation of an XFRM bundle, avoid an XFRM lookup
      altogether whenever we already have a destination entry cached in the
      socket. This prevents the path MTU shrinkage and brings us on par with
      UDPv4.
      
      The fix also benefits connected PINGv6 sockets, another user of
      ip6_sk_dst_lookup_flow(), who also suffer messages being transformed
      twice.
      
      Joint work with Hannes Frederic Sowa.
      Reported-by: NJan Tluka <jtluka@redhat.com>
      Signed-off-by: NJakub Sitnicki <jkbs@redhat.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      00bc0ef5
    • G
      l2tp: fix configuration passed to setup_udp_tunnel_sock() · a5c5e2da
      Guillaume Nault 提交于
      Unused fields of udp_cfg must be all zeros. Otherwise
      setup_udp_tunnel_sock() fills ->gro_receive and ->gro_complete
      callbacks with garbage, eventually resulting in panic when used by
      udp_gro_receive().
      
      [   72.694123] BUG: unable to handle kernel paging request at ffff880033f87d78
      [   72.695518] IP: [<ffff880033f87d78>] 0xffff880033f87d78
      [   72.696530] PGD 26e2067 PUD 26e3067 PMD 342ed063 PTE 8000000033f87163
      [   72.696530] Oops: 0011 [#1] SMP KASAN
      [   72.696530] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pptp gre pppox ppp_generic slhc crc32c_intel ghash_clmulni_intel jitterentropy_rng sha256_generic hmac drbg ansi_cprng aesni_intel evdev aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper serio_raw acpi_cpufreq button proc\
      essor ext4 crc16 jbd2 mbcache virtio_blk virtio_net virtio_pci virtio_ring virtio
      [   72.696530] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.7.0-rc1 #1
      [   72.696530] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
      [   72.696530] task: ffff880035b59700 ti: ffff880035b70000 task.ti: ffff880035b70000
      [   72.696530] RIP: 0010:[<ffff880033f87d78>]  [<ffff880033f87d78>] 0xffff880033f87d78
      [   72.696530] RSP: 0018:ffff880035f87bc0  EFLAGS: 00010246
      [   72.696530] RAX: ffffed000698f996 RBX: ffff88003326b840 RCX: ffffffff814cc823
      [   72.696530] RDX: ffff88003326b840 RSI: ffff880033e48038 RDI: ffff880034c7c780
      [   72.696530] RBP: ffff880035f87c18 R08: 000000000000a506 R09: 0000000000000000
      [   72.696530] R10: ffff880035f87b38 R11: ffff880034b9344d R12: 00000000ebfea715
      [   72.696530] R13: 0000000000000000 R14: ffff880034c7c780 R15: 0000000000000000
      [   72.696530] FS:  0000000000000000(0000) GS:ffff880035f80000(0000) knlGS:0000000000000000
      [   72.696530] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   72.696530] CR2: ffff880033f87d78 CR3: 0000000033c98000 CR4: 00000000000406a0
      [   72.696530] Stack:
      [   72.696530]  ffffffff814cc834 ffff880034b93468 0000001481416818 ffff88003326b874
      [   72.696530]  ffff880034c7ccb0 ffff880033e48038 ffff88003326b840 ffff880034b93462
      [   72.696530]  ffff88003326b88a ffff88003326b88c ffff880034b93468 ffff880035f87c70
      [   72.696530] Call Trace:
      [   72.696530]  <IRQ>
      [   72.696530]  [<ffffffff814cc834>] ? udp_gro_receive+0x1c6/0x1f9
      [   72.696530]  [<ffffffff814ccb1c>] udp4_gro_receive+0x2b5/0x310
      [   72.696530]  [<ffffffff814d989b>] inet_gro_receive+0x4a3/0x4cd
      [   72.696530]  [<ffffffff81431b32>] dev_gro_receive+0x584/0x7a3
      [   72.696530]  [<ffffffff810adf7a>] ? __lock_is_held+0x29/0x64
      [   72.696530]  [<ffffffff814321f7>] napi_gro_receive+0x124/0x21d
      [   72.696530]  [<ffffffffa000b145>] virtnet_receive+0x8df/0x8f6 [virtio_net]
      [   72.696530]  [<ffffffffa000b27e>] virtnet_poll+0x1d/0x8d [virtio_net]
      [   72.696530]  [<ffffffff81431350>] net_rx_action+0x15b/0x3b9
      [   72.696530]  [<ffffffff815893d6>] __do_softirq+0x216/0x546
      [   72.696530]  [<ffffffff81062392>] irq_exit+0x49/0xb6
      [   72.696530]  [<ffffffff81588e9a>] do_IRQ+0xe2/0xfa
      [   72.696530]  [<ffffffff81587a49>] common_interrupt+0x89/0x89
      [   72.696530]  <EOI>
      [   72.696530]  [<ffffffff810b05df>] ? trace_hardirqs_on_caller+0x229/0x270
      [   72.696530]  [<ffffffff8102b3c7>] ? default_idle+0x1c/0x2d
      [   72.696530]  [<ffffffff8102b3c5>] ? default_idle+0x1a/0x2d
      [   72.696530]  [<ffffffff8102bb8c>] arch_cpu_idle+0xa/0xc
      [   72.696530]  [<ffffffff810a6c39>] default_idle_call+0x1a/0x1c
      [   72.696530]  [<ffffffff810a6d96>] cpu_startup_entry+0x15b/0x20f
      [   72.696530]  [<ffffffff81039a81>] start_secondary+0x12c/0x133
      [   72.696530] Code: ff ff ff ff ff ff ff ff ff ff 7f ff ff ff ff ff ff ff 7f 00 7e f8 33 00 88 ff ff 6d 61 58 81 ff ff ff ff 5e de 0a 81 ff ff ff ff <00> 5c e2 34 00 88 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00
      [   72.696530] RIP  [<ffff880033f87d78>] 0xffff880033f87d78
      [   72.696530]  RSP <ffff880035f87bc0>
      [   72.696530] CR2: ffff880033f87d78
      [   72.696530] ---[ end trace ad7758b9a1dccf99 ]---
      [   72.696530] Kernel panic - not syncing: Fatal exception in interrupt
      [   72.696530] Kernel Offset: disabled
      [   72.696530] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
      
      v2: use empty initialiser instead of "{ NULL }" to avoid relying on
          first field's type.
      
      Fixes: 38fd2af2 ("udp: Add socket based GRO and config")
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a5c5e2da
    • H
      c0530dd3
  3. 08 6月, 2016 23 次提交
  4. 07 6月, 2016 3 次提交
  5. 06 6月, 2016 2 次提交
    • M
      bnx2x: allow adding VLANs while interface is down · a02cc9d3
      Michal Schmidt 提交于
      Since implementing VLAN filtering in commit 05cc5a39
      ("bnx2x: add vlan filtering offload") bnx2x refuses to add a VLAN while
      the interface is down:
      
        # ip link add link enp3s0f0 enp3s0f0_10 type vlan id 10
        RTNETLINK answers: Bad address
      
      and in dmesg (with bnx2x.debug=0x20):
        bnx2x: [bnx2x_vlan_rx_add_vid:12941(enp3s0f0)]Ignoring VLAN
        configuration the interface is down
      
      Other drivers have no problem with this.
      Fix this peculiar behavior in the following way:
       - Accept requests to add/kill VID regardless of the device state.
         Maintain the requested list of VIDs in the bp->vlan_reg list.
       - If the device is up, try to configure the VID list into the hardware.
         If we run out of VLAN credits or encounter a failure configuring an
         entry, fall back to accepting all VLANs.
         If we successfully configure all entries from the list, turn the
         fallback off.
       - Use the same code for reconfiguring VLANs during NIC load.
      Signed-off-by: NMichal Schmidt <mschmidt@redhat.com>
      Acked-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a02cc9d3
    • M
      ipvs: update real-server binding of outgoing connections in SIP-pe · 3ec10d3a
      Marco Angaroni 提交于
      Previous patch that introduced handling of outgoing packets in SIP
      persistent-engine did not call ip_vs_check_template() in case packet was
      matching a connection template. Assumption was that real-server was
      healthy, since it was sending a packet just in that moment.
      
      There are however real-server fault conditions requiring that association
      between call-id and real-server (represented by connection template)
      gets updated. Here is an example of the sequence of events:
        1) RS1 is a back2back user agent that handled call-id1 and call-id2
        2) RS1 is down and was marked as unavailable
        3) new message from outside comes to IPVS with call-id1
        4) IPVS reschedules the message to RS2, which becomes new call handler
        5) RS2 forwards the message outside, translating call-id1 to call-id2
        6) inside pe->conn_out() IPVS matches call-id2 with existing template
        7) IPVS does not change association call-id2 <-> RS1
        8) new message comes from client with call-id2
        9) IPVS reschedules the message to a real-server potentially different
           from RS2, which is now the correct destination
      
      This patch introduces ip_vs_check_template() call in the handling of
      outgoing packets for SIP-pe. And also introduces a second optional
      argument for ip_vs_check_template() that allows to check if dest
      associated to a connection template is the same dest that was identified
      as the source of the packet. This is to change the real-server bound to a
      particular call-id independently from its availability status: the idea
      is that it's more reliable, for in->out direction (where internal
      network can be considered trusted), to always associate a call-id with
      the last real-server that used it in one of its messages. Think about
      above sequence of events where, just after step 5, RS1 returns instead
      to be available.
      
      Comparison of dests is done by simply comparing pointers to struct
      ip_vs_dest; there should be no cases where struct ip_vs_dest keeps its
      memory address, but represent a different real-server in terms of
      ip-address / port.
      
      Fixes: 39b97223 ("ipvs: handle connections started by real-servers")
      Signed-off-by: NMarco Angaroni <marcoangaroni@gmail.com>
      Acked-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      3ec10d3a
  6. 05 6月, 2016 1 次提交