1. 09 Aug, 2017 8 commits
    • Willem de Bruijn's avatar
      net: avoid skb_warn_bad_offload false positives on UFO · 8d63bee6
      Willem de Bruijn authored
      skb_warn_bad_offload triggers a warning when an skb enters the GSO
      stack at __skb_gso_segment that does not have CHECKSUM_PARTIAL
      checksum offload set.
      
      Commit b2504a5d ("net: reduce skb_warn_bad_offload() noise")
      observed that SKB_GSO_DODGY producers can trigger the check and
      that passing those packets through the GSO handlers will fix it
      up. But, the software UFO handler will set ip_summed to
      CHECKSUM_NONE.
      
      When __skb_gso_segment is called from the receive path, this
      triggers the warning again.
      
      Make UFO set CHECKSUM_UNNECESSARY instead of CHECKSUM_NONE. On
      Tx these two are equivalent. On Rx, this better matches the
      skb state (checksum computed), as CHECKSUM_NONE here means no
      checksum computed.
      
      See also this thread for context:
      http://patchwork.ozlabs.org/patch/799015/
      
      Fixes: b2504a5d ("net: reduce skb_warn_bad_offload() noise")
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8d63bee6
    • Bjørn Mork's avatar
      qmi_wwan: fix NULL deref on disconnect · bbae08e5
      Bjørn Mork authored
      qmi_wwan_disconnect is called twice when disconnecting devices with
      separate control and data interfaces.  The first invocation will set
      the interface data to NULL for both interfaces to flag that the
      disconnect has been handled.  But the matching NULL check was left
      out when qmi_wwan_disconnect was added, resulting in this oops:
      
        usb 2-1.4: USB disconnect, device number 4
        qmi_wwan 2-1.4:1.6 wwp0s29u1u4i6: unregister 'qmi_wwan' usb-0000:00:1d.0-1.4, WWAN/QMI device
        BUG: unable to handle kernel NULL pointer dereference at 00000000000000e0
        IP: qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan]
        PGD 0
        P4D 0
        Oops: 0000 [#1] SMP
        Modules linked in: <stripped irrelevant module list>
        CPU: 2 PID: 33 Comm: kworker/2:1 Tainted: G            E   4.12.3-nr44-normandy-r1500619820+ #1
        Hardware name: LENOVO 4291LR7/4291LR7, BIOS CBET4000 4.6-810-g50522254fb 07/21/2017
        Workqueue: usb_hub_wq hub_event [usbcore]
        task: ffff8c882b716040 task.stack: ffffb8e800d84000
        RIP: 0010:qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan]
        RSP: 0018:ffffb8e800d87b38 EFLAGS: 00010246
        RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
        RDX: 0000000000000001 RSI: ffff8c8824f3f1d0 RDI: ffff8c8824ef6400
        RBP: ffff8c8824ef6400 R08: 0000000000000000 R09: 0000000000000000
        R10: ffffb8e800d87780 R11: 0000000000000011 R12: ffffffffc07ea0e8
        R13: ffff8c8824e2e000 R14: ffff8c8824e2e098 R15: 0000000000000000
        FS:  0000000000000000(0000) GS:ffff8c8835300000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00000000000000e0 CR3: 0000000229ca5000 CR4: 00000000000406e0
        Call Trace:
         ? usb_unbind_interface+0x71/0x270 [usbcore]
         ? device_release_driver_internal+0x154/0x210
         ? qmi_wwan_unbind+0x6d/0xc0 [qmi_wwan]
         ? usbnet_disconnect+0x6c/0xf0 [usbnet]
         ? qmi_wwan_disconnect+0x87/0xc0 [qmi_wwan]
         ? usb_unbind_interface+0x71/0x270 [usbcore]
         ? device_release_driver_internal+0x154/0x210
      Reported-and-tested-by: default avatarNathaniel Roach <nroach44@gmail.com>
      Fixes: c6adf779 ("net: usb: qmi_wwan: add qmap mux protocol support")
      Cc: Daniele Palmas <dnlplm@gmail.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bbae08e5
    • Guillaume Nault's avatar
      ppp: fix xmit recursion detection on ppp channels · 0a0e1a85
      Guillaume Nault authored
      Commit e5dadc65 ("ppp: Fix false xmit recursion detect with two ppp
      devices") dropped the xmit_recursion counter incrementation in
      ppp_channel_push() and relied on ppp_xmit_process() for this task.
      But __ppp_channel_push() can also send packets directly (using the
      .start_xmit() channel callback), in which case the xmit_recursion
      counter isn't incremented anymore. If such packets get routed back to
      the parent ppp unit, ppp_xmit_process() won't notice the recursion and
      will call ppp_channel_push() on the same channel, effectively creating
      the deadlock situation that the xmit_recursion mechanism was supposed
      to prevent.
      
      This patch re-introduces the xmit_recursion counter incrementation in
      ppp_channel_push(). Since the xmit_recursion variable is now part of
      the parent ppp unit, incrementation is skipped if the channel doesn't
      have any. This is fine because only packets routed through the parent
      unit may enter the channel recursively.
      
      Finally, we have to ensure that pch->ppp is not going to be modified
      while executing ppp_channel_push(). Instead of taking this lock only
      while calling ppp_xmit_process(), we now have to hold it for the full
      ppp_channel_push() execution. This respects the ppp locks ordering
      which requires locking ->upl before ->downl.
      
      Fixes: e5dadc65 ("ppp: Fix false xmit recursion detect with two ppp devices")
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0a0e1a85
    • Håkon Bugge's avatar
      rds: Reintroduce statistics counting · 05bfd7db
      Håkon Bugge authored
      In commit 7e3f2952 ("rds: don't let RDS shutdown a connection
      while senders are present"), refilling the receive queue was removed
      from rds_ib_recv(), along with the increment of
      s_ib_rx_refill_from_thread.
      
      Commit 73ce4317 ("RDS: make sure we post recv buffers")
      re-introduces filling the receive queue from rds_ib_recv(), but does
      not add the statistics counter. rds_ib_recv() was later renamed to
      rds_ib_recv_path().
      
      This commit reintroduces the statistics counting of
      s_ib_rx_refill_from_thread and s_ib_rx_refill_from_cq.
      Signed-off-by: default avatarHåkon Bugge <haakon.bugge@oracle.com>
      Reviewed-by: default avatarKnut Omang <knut.omang@oracle.com>
      Reviewed-by: default avatarWei Lin Guay <wei.lin.guay@oracle.com>
      Reviewed-by: default avatarShamir Rabinovitch <shamir.rabinovitch@oracle.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      05bfd7db
    • Eric Dumazet's avatar
      tcp: fastopen: tcp_connect() must refresh the route · 8ba60924
      Eric Dumazet authored
      With new TCP_FASTOPEN_CONNECT socket option, there is a possibility
      to call tcp_connect() while socket sk_dst_cache is either NULL
      or invalid.
      
       +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 4
       +0 fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
       +0 setsockopt(4, SOL_TCP, TCP_FASTOPEN_CONNECT, [1], 4) = 0
       +0 connect(4, ..., ...) = 0
      
      << sk->sk_dst_cache becomes obsolete, or even set to NULL >>
      
       +1 sendto(4, ..., 1000, MSG_FASTOPEN, ..., ...) = 1000
      
      We need to refresh the route otherwise bad things can happen,
      especially when syzkaller is running on the host :/
      
      Fixes: 19f6d3f3 ("net/tcp-fastopen: Add new API support")
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Wei Wang <weiwan@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Acked-by: default avatarWei Wang <weiwan@google.com>
      Acked-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ba60924
    • Xin Long's avatar
      net: sched: set xt_tgchk_param par.net properly in ipt_init_target · ec0acb09
      Xin Long authored
      Now xt_tgchk_param par in ipt_init_target is a local varibale,
      par.net is not initialized there. Later when xt_check_target
      calls target's checkentry in which it may access par.net, it
      would cause kernel panic.
      
      Jaroslav found this panic when running:
      
        # ip link add TestIface type dummy
        # tc qd add dev TestIface ingress handle ffff:
        # tc filter add dev TestIface parent ffff: u32 match u32 0 0 \
          action xt -j CONNMARK --set-mark 4
      
      This patch is to pass net param into ipt_init_target and set
      par.net with it properly in there.
      
      v1->v2:
        As Wang Cong pointed, I missed ipt_net_id != xt_net_id, so fix
        it by also passing net_id to __tcf_ipt_init.
      v2->v3:
        Missed the fixes tag, so add it.
      
      Fixes: ecb2421b ("netfilter: add and use nf_ct_netns_get/put")
      Reported-by: default avatarJaroslav Aster <jaster@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ec0acb09
    • John Crispin's avatar
      net: dsa: mediatek: add adjust link support for user ports · 8e6f1521
      John Crispin authored
      Manually adjust the port settings of user ports once PHY polling has
      completed. This patch extends the adjust_link callback to configure the
      per port PMCR register, applying the proper values polled from the PHY.
      Without this patch flow control was not always getting setup properly.
      Signed-off-by: default avatarShashidhar Lakkavalli <shashidhar.lakkavalli@openmesh.com>
      Signed-off-by: default avatarMuciri Gatimu <muciri@openmesh.com>
      Signed-off-by: default avatarJohn Crispin <john@phrozen.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e6f1521
    • Davide Caratti's avatar
      net/mlx4_en: don't set CHECKSUM_COMPLETE on SCTP packets · e718fe45
      Davide Caratti authored
      if the NIC fails to validate the checksum on TCP/UDP, and validation of IP
      checksum is successful, the driver subtracts the pseudo-header checksum
      from the value obtained by the hardware and sets CHECKSUM_COMPLETE. Don't
      do that if protocol is IPPROTO_SCTP, otherwise CRC32c validation fails.
      
      V2: don't test MLX4_CQE_STATUS_IPV6 if MLX4_CQE_STATUS_IPV4 is set
      Reported-by: default avatarShuang Li <shuali@redhat.com>
      Fixes: f8c6455b ("net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Acked-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e718fe45
  2. 07 Aug, 2017 9 commits
    • Christophe Jaillet's avatar
      qed: Fix a memory allocation failure test in 'qed_mcp_cmd_init()' · eb2a6b80
      Christophe Jaillet authored
      We allocate 'p_info->mfw_mb_cur' and 'p_info->mfw_mb_shadow' but we check
      'p_info->mfw_mb_addr' instead of 'p_info->mfw_mb_cur'.
      
      'p_info->mfw_mb_addr' is never 0, because it is initiliazed a few lines
      above in 'qed_load_mcp_offsets()'.
      
      Update the test and check the result of the 2 'kzalloc()' instead.
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Acked-by: default avatarTomer Tayar <Tomer.Tayar@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb2a6b80
    • Anton Volkov's avatar
      hysdn: fix to a race condition in put_log_buffer · b925ef37
      Anton Volkov authored
      The synchronization type that was used earlier to guard the loop that
      deletes unused log buffers may lead to a situation that prevents any
      thread from going through the loop.
      
      The patch deletes previously used synchronization mechanism and moves
      the loop under the spin_lock so the similar cases won't be feasible in
      the future.
      
      Found by by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: default avatarAnton Volkov <avolkov@ispras.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b925ef37
    • Julian Wiedmann's avatar
      s390/qeth: fix L3 next-hop in xmit qeth hdr · ec2c6726
      Julian Wiedmann authored
      On L3, the qeth_hdr struct needs to be filled with the next-hop
      IP address.
      The current code accesses rtable->rt_gateway without checking that
      rtable is a valid address. The accidental access to a lowcore area
      results in a random next-hop address in the qeth_hdr.
      rtable (or more precisely, skb_dst(skb)) can be NULL in rare cases
      (for instance together with AF_PACKET sockets).
      This patch adds the missing NULL-ptr checks.
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: default avatarUrsula Braun <ubraun@linux.vnet.ibm.com>
      Fixes: 87e7597b qeth: Move away from using neighbour entries in qeth_l3_fill_header()
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ec2c6726
    • David S. Miller's avatar
      Merge branch 'asix-Improve-robustness' · c0e0fb83
      David S. Miller authored
      Dean Jenkins says:
      
      ====================
      asix: Improve robustness
      
      Please consider taking these patches to improve the robustness of the ASIX USB
      to Ethernet driver.
      
      Failures prompting an ASIX driver code review
      =============================================
      
      On an ARM i.MX6 embedded platform some strange one-off and two-off failures were
      observed in and around the ASIX USB to Ethernet driver. This was observed on a
      highly modified kernel 3.14 with the ASIX driver containing back-ported changes
      from kernel.org up to kernel 4.8 approximately.
      
      a) A one-off failure in asix_rx_fixup_internal():
      
      There was an occurrence of an attempt to write off the end of the netdev buffer
      which was trapped by skb_over_panic() in skb_put().
      
      [20030.846440] skbuff: skb_over_panic: text:7f2271c0 len:120 put:60 head:8366ecc0 data:8366ed02 tail:0x8366ed7a end:0x8366ed40 dev:eth0
      [20030.863007] Kernel BUG at 8044ce38 [verbose debug info unavailable]
      
      [20031.215345] Backtrace:
      [20031.217884] [<8044cde0>] (skb_panic) from [<8044d50c>] (skb_put+0x50/0x5c)
      [20031.227408] [<8044d4bc>] (skb_put) from [<7f2271c0>] (asix_rx_fixup_internal+0x1c4/0x23c [asix])
      [20031.242024] [<7f226ffc>] (asix_rx_fixup_internal [asix]) from [<7f22724c>] (asix_rx_fixup_common+0x14/0x18 [asix])
      [20031.260309] [<7f227238>] (asix_rx_fixup_common [asix]) from [<7f21f7d4>] (usbnet_bh+0x74/0x224 [usbnet])
      [20031.269879] [<7f21f760>] (usbnet_bh [usbnet]) from [<8002f834>] (call_timer_fn+0xa4/0x1f0)
      [20031.283961] [<8002f790>] (call_timer_fn) from [<80030834>] (run_timer_softirq+0x230/0x2a8)
      [20031.302782] [<80030604>] (run_timer_softirq) from [<80028780>] (__do_softirq+0x15c/0x37c)
      [20031.321511] [<80028624>] (__do_softirq) from [<80028c38>] (irq_exit+0x8c/0xe8)
      [20031.339298] [<80028bac>] (irq_exit) from [<8000e9c8>] (handle_IRQ+0x8c/0xc8)
      [20031.350038] [<8000e93c>] (handle_IRQ) from [<800085c8>] (gic_handle_irq+0xb8/0xf8)
      [20031.365528] [<80008510>] (gic_handle_irq) from [<8050de80>] (__irq_svc+0x40/0x70)
      
      Analysis of the logic of the ASIX driver (containing backported changes from
      kernel.org up to kernel 4.8 approximately) suggested that the software could not
      trigger skb_over_panic(). The analysis of the kernel BUG() crash information
      suggested that the netdev buffer was written with 2 minimal 60 octet length
      Ethernet frames (ASIX hardware drops the 4 octet FCS field) and the 2nd Ethernet
      frame attempted to write off the end of the netdev buffer.
      
      Note that the netdev buffer should only contain 1 Ethernet frame so if an
      attempt to write 2 Ethernet frames into the buffer is made then that is wrong.
      However, the logic of the asix_rx_fixup_internal() only allows 1 Ethernet frame
      to be written into the netdev buffer.
      
      Potentially this failure was due to memory corruption because it was only seen
      once.
      
      b) Two-off failures in the NAPI layer's backlog queue:
      
      There were 2 crashes in the NAPI layer's backlog queue presumably after
      asix_rx_fixup_internal() called usbnet_skb_return().
      
      [24097.273945] Unable to handle kernel NULL pointer dereference at virtual address 00000004
      
      [24097.398944] PC is at process_backlog+0x80/0x16c
      
      [24097.569466] Backtrace:
      [24097.572007] [<8045ad98>] (process_backlog) from [<8045b64c>] (net_rx_action+0xcc/0x248)
      [24097.591631] [<8045b580>] (net_rx_action) from [<80028780>] (__do_softirq+0x15c/0x37c)
      [24097.610022] [<80028624>] (__do_softirq) from [<800289cc>] (run_ksoftirqd+0x2c/0x84)
      
      and
      
      [ 1059.828452] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      
      [ 1059.953715] PC is at process_backlog+0x84/0x16c
      
      [ 1060.140896] Backtrace:
      [ 1060.143434] [<8045ad98>] (process_backlog) from [<8045b64c>] (net_rx_action+0xcc/0x248)
      [ 1060.163075] [<8045b580>] (net_rx_action) from [<80028780>] (__do_softirq+0x15c/0x37c)
      [ 1060.181474] [<80028624>] (__do_softirq) from [<80028c38>] (irq_exit+0x8c/0xe8)
      [ 1060.199256] [<80028bac>] (irq_exit) from [<8000e9c8>] (handle_IRQ+0x8c/0xc8)
      [ 1060.210006] [<8000e93c>] (handle_IRQ) from [<800085c8>] (gic_handle_irq+0xb8/0xf8)
      [ 1060.225492] [<80008510>] (gic_handle_irq) from [<8050de80>] (__irq_svc+0x40/0x70)
      
      The embedded board was only using an ASIX USB to Ethernet adaptor eth0.
      
      Analysis suggested that the doubly-linked list pointers of the backlog queue had
      been corrupted because one of the link pointers was NULL.
      
      Potentially this failure was due to memory corruption because it was only seen
      twice.
      
      Results of the ASIX driver code review
      ======================================
      
      During the code review some weaknesses were observed in the ASIX driver and the
      following patches have been created to improve the robustness.
      
      Brief overview of the patches
      -----------------------------
      
      1. asix: Add rx->ax_skb = NULL after usbnet_skb_return()
      
      The current ASIX driver sends the received Ethernet frame to the NAPI layer of
      the network stack via the call to usbnet_skb_return() in
      asix_rx_fixup_internal() but retains the rx->ax_skb pointer to the netdev
      buffer. The driver no longer needs the rx->ax_skb pointer at this point because
      the NAPI layer now has the Ethernet frame.
      
      This means that asix_rx_fixup_internal() must not use rx->ax_skb after the call
      to usbnet_skb_return() because it could corrupt the handling of the Ethernet
      frame within the network layer.
      
      Therefore, to remove the risk of erroneous usage of rx->ax_skb, set rx->ax_skb
      to NULL after the call to usbnet_skb_return(). This avoids potential erroneous
      freeing of rx->ax_skb and erroneous writing to the netdev buffer.  If the
      software now somehow inappropriately reused rx->ax_skb, then a NULL pointer
      dereference of rx->ax_skb would occur which makes investigation easier.
      
      2. asix: Ensure asix_rx_fixup_info members are all reset
      
      This patch creates reset_asix_rx_fixup_info() to allow all the
      asix_rx_fixup_info structure members to be consistently reset to initial
      conditions.
      
      Call reset_asix_rx_fixup_info() upon each detectable error condition so that the
      next URB is processed from a known state.
      
      Otherwise, there is a risk that some members of the asix_rx_fixup_info structure
      may be incorrect after an error occurred so potentially leading to a
      malfunction.
      
      3. asix: Fix small memory leak in ax88772_unbind()
      
      This patch creates asix_rx_fixup_common_free() to allow the rx->ax_skb to be
      freed when necessary.
      
      asix_rx_fixup_common_free() is called from ax88772_unbind() before the parent
      private data structure is freed.
      
      Without this patch, there is a risk of a small netdev buffer memory leak each
      time ax88772_unbind() is called during the reception of an Ethernet frame that
      spans across 2 URBs.
      
      Testing
      =======
      
      The patches have been sanity tested on a 64-bit Linux laptop running kernel
      4.13-rc2 with the 3 patches applied on top.
      
      The ASIX USB to Adaptor used for testing was (output of lsusb):
      ID 0b95:772b ASIX Electronics Corp. AX88772B
      
      Test #1
      -------
      
      The test ran a flood ping test script which slowly incremented the ICMP Echo
      Request's payload from 0 to 5000 octets. This eventually causes IPv4
      fragmentation to occur which causes Ethernet frames to be sent very close to
      each other so increases the probability that an Ethernet frame will span 2 URBs.
      The test showed that all pings were successful. The test took about 15 minutes
      to complete.
      
      Test #2
      -------
      
      A script was run on the laptop to periodically run ifdown and ifup every second
      so that the ASIX USB to Adaptor was up for 1 second and down for 1 second.
      
      From a Linux PC connected to the laptop, the following ping command was used
      ping -f -s 5000 <ip address of laptop>
      
      The large ICMP payload causes IPv4 fragmentation resulting in multiple
      Ethernet frames per original IP packet.
      
      Kernel debug within the ASIX driver was enabled to see whether any ASIX errors
      were generated. The test was run for about 24 hours and no ASIX errors were
      seen.
      
      Patches
      =======
      
      The 3 patches have been rebased off the net-next repo master branch with HEAD
      fbbeefdd net: fec: Allow reception of frames bigger than 1522 bytes
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0e0fb83
    • Dean Jenkins's avatar
      asix: Fix small memory leak in ax88772_unbind() · d0c8f338
      Dean Jenkins authored
      When Ethernet frames span mulitple URBs, the netdev buffer memory
      pointed to by the asix_rx_fixup_info structure remains allocated
      during the time gap between the 2 executions of asix_rx_fixup_internal().
      
      This means that if ax88772_unbind() is called within this time
      gap to free the memory of the parent private data structure then
      a memory leak of the part filled netdev buffer memory will occur.
      
      Therefore, create a new function asix_rx_fixup_common_free() to
      free the memory of the netdev buffer and add a call to
      asix_rx_fixup_common_free() from inside ax88772_unbind().
      
      Consequently when an unbind occurs part way through receiving
      an Ethernet frame, the netdev buffer memory that is holding part
      of the received Ethernet frame will now be freed.
      Signed-off-by: default avatarDean Jenkins <Dean_Jenkins@mentor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0c8f338
    • Dean Jenkins's avatar
      asix: Ensure asix_rx_fixup_info members are all reset · 960eb4ee
      Dean Jenkins authored
      There is a risk that the members of the structure asix_rx_fixup_info
      become unsynchronised leading to the possibility of a malfunction.
      
      For example, rx->split_head was not being set to false after an
      error was detected so potentially could cause a malformed 32-bit
      Data header word to be formed.
      
      Therefore add function reset_asix_rx_fixup_info() to reset all the
      members of asix_rx_fixup_info so that future processing will start
      with known initial conditions.
      
      Also, if (skb->len != offset) becomes true then call
      reset_asix_rx_fixup_info() so that the processing of the next URB
      starts with known initial conditions. Without the call, the check
      does nothing which potentially could lead to a malfunction
      when the next URB is processed.
      
      In addition, for robustness, call reset_asix_rx_fixup_info() before
      every error path's "return 0". This ensures that the next URB is
      processed from known initial conditions.
      Signed-off-by: default avatarDean Jenkins <Dean_Jenkins@mentor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      960eb4ee
    • Dean Jenkins's avatar
      asix: Add rx->ax_skb = NULL after usbnet_skb_return() · 22889dbb
      Dean Jenkins authored
      In asix_rx_fixup_internal() there is a risk that rx->ax_skb gets
      reused after passing the Ethernet frame into the network stack via
      usbnet_skb_return().
      
      The risks include:
      
      a) asynchronously freeing rx->ax_skb after passing the netdev buffer
         to the NAPI layer which might corrupt the backlog queue.
      
      b) erroneously reusing rx->ax_skb such as calling skb_put_data() multiple
         times which causes writing off the end of the netdev buffer.
      
      Therefore add a defensive rx->ax_skb = NULL after usbnet_skb_return()
      so that it is not possible to free rx->ax_skb or to apply
      skb_put_data() too many times.
      Signed-off-by: default avatarDean Jenkins <Dean_Jenkins@mentor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      22889dbb
    • Thomas Richter's avatar
      bpf: fix selftest/bpf/test_pkt_md_access on s390x · f9ea3225
      Thomas Richter authored
      Commit 18f3d6be ("selftests/bpf: Add test cases to test narrower ctx field loads")
      introduced new eBPF test cases. One of them (test_pkt_md_access.c)
      fails on s390x. The BPF verifier error message is:
      
      [root@s8360046 bpf]# ./test_progs
      test_pkt_access:PASS:ipv4 349 nsec
      test_pkt_access:PASS:ipv6 212 nsec
      [....]
      libbpf: load bpf program failed: Permission denied
      libbpf: -- BEGIN DUMP LOG ---
      libbpf:
      0: (71) r2 = *(u8 *)(r1 +0)
      invalid bpf_context access off=0 size=1
      
      libbpf: -- END LOG --
      libbpf: failed to load program 'test1'
      libbpf: failed to load object './test_pkt_md_access.o'
      Summary: 29 PASSED, 1 FAILED
      [root@s8360046 bpf]#
      
      This is caused by a byte endianness issue. S390x is a big endian
      architecture.  Pointer access to the lowest byte or halfword of a
      four byte value need to add an offset.
      On little endian architectures this offset is not needed.
      
      Fix this and use the same approach as the originator used for other files
      (for example test_verifier.c) in his original commit.
      
      With this fix the test program test_progs succeeds on s390x:
      [root@s8360046 bpf]# ./test_progs
      test_pkt_access:PASS:ipv4 236 nsec
      test_pkt_access:PASS:ipv6 217 nsec
      test_xdp:PASS:ipv4 3624 nsec
      test_xdp:PASS:ipv6 1722 nsec
      test_l4lb:PASS:ipv4 926 nsec
      test_l4lb:PASS:ipv6 1322 nsec
      test_tcp_estats:PASS: 0 nsec
      test_bpf_obj_id:PASS:get-fd-by-notexist-prog-id 0 nsec
      test_bpf_obj_id:PASS:get-fd-by-notexist-map-id 0 nsec
      test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
      test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
      test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
      test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
      test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
      test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
      test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
      test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
      test_bpf_obj_id:PASS:check total prog id found by get_next_id 0 nsec
      test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
      test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
      test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
      test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
      test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
      test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
      test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
      test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
      test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
      test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
      test_bpf_obj_id:PASS:check total map id found by get_next_id 0 nsec
      test_pkt_md_access:PASS: 277 nsec
      Summary: 30 PASSED, 0 FAILED
      [root@s8360046 bpf]#
      
      Fixes: 18f3d6be ("selftests/bpf: Add test cases to test narrower ctx field loads")
      Signed-off-by: default avatarThomas Richter <tmricht@linux.vnet.ibm.com>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9ea3225
    • stephen hemminger's avatar
      netvsc: fix race on sub channel creation · 732e4985
      stephen hemminger authored
      The existing sub channel code did not wait for all the sub-channels
      to completely initialize. This could lead to race causing crash
      in napi_netif_del() from bad list. The existing code would send
      an init message, then wait only for the initial response that
      the init message was received. It thought it was waiting for
      sub channels but really the init response did the wakeup.
      
      The new code keeps track of the number of open channels and
      waits until that many are open.
      
      Other issues here were:
        * host might return less sub-channels than was requested.
        * the new init status is not valid until after init was completed.
      
      Fixes: b3e6b82a ("hv_netvsc: Wait for sub-channels to be processed during probe")
      Signed-off-by: default avatarStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      732e4985
  3. 04 Aug, 2017 9 commits
    • Daniel Borkmann's avatar
      bpf: fix byte order test in test_verifier · 2c460621
      Daniel Borkmann authored
      We really must check with #if __BYTE_ORDER == XYZ instead of
      just presence of #ifdef __LITTLE_ENDIAN. I noticed that when
      actually running this on big endian machine, the latter test
      resolves to true for user space, same for #ifdef __BIG_ENDIAN.
      
      E.g., looking at endian.h from libc, both are also defined
      there, so we really must test this against __BYTE_ORDER instead
      for proper insns selection. For the kernel, such checks are
      fine though e.g. see 13da9e20 ("Revert "endian: #define
      __BYTE_ORDER"") and 415586c9 ("UAPI: fix endianness conditionals
      in M32R's asm/stat.h") for some more context, but not for
      user space. Lets also make sure to properly include endian.h.
      After that, suite passes for me:
      
      ./test_verifier: ELF 64-bit MSB executable, [...]
      
      Linux foo 4.13.0-rc3+ #4 SMP Fri Aug 4 06:59:30 EDT 2017 s390x s390x s390x GNU/Linux
      
      Before fix: Summary: 505 PASSED, 11 FAILED
      After  fix: Summary: 516 PASSED,  0 FAILED
      
      Fixes: 18f3d6be ("selftests/bpf: Add test cases to test narrower ctx field loads")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarYonghong <yhs@fb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2c460621
    • Thomas Bogendoerfer's avatar
      xgene: Always get clk source, but ignore if it's missing for SGMII ports · aaf83aec
      Thomas Bogendoerfer authored
      Even the driver doesn't do anything with the clk source for SGMII
      ports it needs to be enabled by doing a devm_clk_get(), if there is
      a clk source in DT.
      
      Fixes: 0db01097 ('xgene: Don't fail probe, if there is no clk resource for SGMII interfaces')
      Signed-off-by: default avatarThomas Bogendoerfer <tbogendoerfer@suse.de>
      Tested-by: default avatarLaura Abbott <labbott@redhat.com>
      Acked-by: default avatarIyappan Subramanian <isubramanian@apm.com>
      Tested-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aaf83aec
    • David Daney's avatar
      MIPS: Add missing file for eBPF JIT. · b6bd53f9
      David Daney authored
      Inexplicably, commit f381bf6d ("MIPS: Add support for eBPF JIT.")
      lost a file somewhere on its path to Linus' tree.  Add back the
      missing ebpf_jit.c so that we can build with CONFIG_BPF_JIT selected.
      
      This version of ebpf_jit.c is identical to the original except for two
      minor change need to resolve conflicts with changes merged from the
      BPF branch:
      
      A) Set prog->jited_len = image_size;
      B) Use BPF_TAIL_CALL instead of BPF_CALL | BPF_X
      
      Fixes: f381bf6d ("MIPS: Add support for eBPF JIT.")
      Signed-off-by: default avatarDavid Daney <david.daney@cavium.com>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b6bd53f9
    • David S. Miller's avatar
      Merge branch 's390-bpf-jit-fixes' · 7a973251
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      Two BPF fixes for s390
      
      Found while testing some other work touching JITs.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7a973251
    • Daniel Borkmann's avatar
      bpf, s390: fix build for libbpf and selftest suite · bad1926d
      Daniel Borkmann authored
      The BPF feature test as well as libbpf is missing the __NR_bpf
      define for s390 and currently refuses to compile (selftest suite
      depends on libbpf as well). Similar issue was fixed some time
      ago via b0c47807 ("bpf: Add sparc support to tools and
      samples."), just do the same and add definitions.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bad1926d
    • Daniel Borkmann's avatar
      bpf, s390: fix jit branch offset related to ldimm64 · b0a0c256
      Daniel Borkmann authored
      While testing some other work that required JIT modifications, I
      run into test_bpf causing a hang when JIT enabled on s390. The
      problematic test case was the one from ddc665a4 (bpf, arm64:
      fix jit branch offset related to ldimm64), and turns out that we
      do have a similar issue on s390 as well. In bpf_jit_prog() we
      update next instruction address after returning from bpf_jit_insn()
      with an insn_count. bpf_jit_insn() returns either -1 in case of
      error (e.g. unsupported insn), 1 or 2. The latter is only the
      case for ldimm64 due to spanning 2 insns, however, next address
      is only set to i + 1 not taking actual insn_count into account,
      thus fix is to use insn_count instead of 1. bpf_jit_enable in
      mode 2 provides also disasm on s390:
      
      Before fix:
      
        000003ff800349b6: a7f40003   brc     15,3ff800349bc                 ; target
        000003ff800349ba: 0000               unknown
        000003ff800349bc: e3b0f0700024       stg     %r11,112(%r15)
        000003ff800349c2: e3e0f0880024       stg     %r14,136(%r15)
        000003ff800349c8: 0db0               basr    %r11,%r0
        000003ff800349ca: c0ef00000000       llilf   %r14,0
        000003ff800349d0: e320b0360004       lg      %r2,54(%r11)
        000003ff800349d6: e330b03e0004       lg      %r3,62(%r11)
        000003ff800349dc: ec23ffeda065       clgrj   %r2,%r3,10,3ff800349b6 ; jmp
        000003ff800349e2: e3e0b0460004       lg      %r14,70(%r11)
        000003ff800349e8: e3e0b04e0004       lg      %r14,78(%r11)
        000003ff800349ee: b904002e   lgr     %r2,%r14
        000003ff800349f2: e3b0f0700004       lg      %r11,112(%r15)
        000003ff800349f8: e3e0f0880004       lg      %r14,136(%r15)
        000003ff800349fe: 07fe               bcr     15,%r14
      
      After fix:
      
        000003ff80ef3db4: a7f40003   brc     15,3ff80ef3dba
        000003ff80ef3db8: 0000               unknown
        000003ff80ef3dba: e3b0f0700024       stg     %r11,112(%r15)
        000003ff80ef3dc0: e3e0f0880024       stg     %r14,136(%r15)
        000003ff80ef3dc6: 0db0               basr    %r11,%r0
        000003ff80ef3dc8: c0ef00000000       llilf   %r14,0
        000003ff80ef3dce: e320b0360004       lg      %r2,54(%r11)
        000003ff80ef3dd4: e330b03e0004       lg      %r3,62(%r11)
        000003ff80ef3dda: ec230006a065       clgrj   %r2,%r3,10,3ff80ef3de6 ; jmp
        000003ff80ef3de0: e3e0b0460004       lg      %r14,70(%r11)
        000003ff80ef3de6: e3e0b04e0004       lg      %r14,78(%r11)          ; target
        000003ff80ef3dec: b904002e   lgr     %r2,%r14
        000003ff80ef3df0: e3b0f0700004       lg      %r11,112(%r15)
        000003ff80ef3df6: e3e0f0880004       lg      %r14,136(%r15)
        000003ff80ef3dfc: 07fe               bcr     15,%r14
      
      test_bpf.ko suite runs fine after the fix.
      
      Fixes: 05462310 ("s390/bpf: Add s390x eBPF JIT compiler backend")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Tested-by: default avatarMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b0a0c256
    • David S. Miller's avatar
      Merge branch 'mlxsw-Couple-of-fixes' · 1aff0c34
      David S. Miller authored
      Jiri Pirko says:
      
      ====================
      mlxsw: Couple of fixes
      
      Ido says:
      
      The first patch prevents us from warning about valid situations that can
      happen due to the fact that some operations in switchdev are deferred.
      
      Second patch fixes a long standing problem in which we didn't correctly
      free resources upon module removal, resulting in a memory leak.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1aff0c34
    • Ido Schimmel's avatar
      mlxsw: spectrum_switchdev: Release multicast groups during fini · 852cfeed
      Ido Schimmel authored
      Each multicast group (MID) stores a bitmap of ports to which a packet
      should be forwarded to in case an MDB entry associated with the MID is
      hit.
      
      Since the initial introduction of IGMP snooping in commit 3a49b4fd
      ("mlxsw: Adding layer 2 multicast support") the driver didn't correctly
      free these multicast groups upon ungraceful situations such as the
      removal of the upper bridge device or module removal.
      
      The correct way to fix this is to associate each MID with the bridge
      ports member in it and then drop the reference in case the bridge port
      is destroyed, but this will result in a lot more code and will be fixed
      in net-next.
      
      For now, upon module removal, traverse the MID list and release each
      one.
      
      Fixes: 3a49b4fd ("mlxsw: Adding layer 2 multicast support")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      852cfeed
    • Ido Schimmel's avatar
      mlxsw: spectrum_switchdev: Don't warn about valid situations · 17b334a8
      Ido Schimmel authored
      Some operations in the bridge driver such as MDB deletion are preformed
      in an atomic context and thus deferred to a process context by the
      switchdev infrastructure.
      
      Therefore, by the time the operation is performed by the underlying
      device driver it's possible the bridge port context is already gone.
      This is especially true for removal flows, but theoretically can also be
      invoked during addition.
      
      Remove the warnings in such situations and return normally.
      
      Fixes: c57529e1 ("mlxsw: spectrum: Replace vPorts with Port-VLAN")
      Fixes: 3922285d ("net: bridge: Add support for offloading port attributes")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      17b334a8
  4. 03 Aug, 2017 7 commits
    • David S. Miller's avatar
      Merge branch 'tcp-xmit-timer-rearming' · 337f1b07
      David S. Miller authored
      Neal Cardwell says:
      
      ====================
      tcp: fix xmit timer rearming to avoid stalls
      
      This patch series is a bug fix for a TCP loss recovery performance bug
      reported independently in recent netdev threads:
      
       (i)  July 26, 2017: netdev thread "TCP fast retransmit issues"
       (ii) July 26, 2017: netdev thread:
             "[PATCH V2 net-next] TLP: Don't reschedule PTO when there's one
             outstanding TLP retransmission"
      
      Many thanks to Klavs Klavsen and Mao Wenan for the detailed reports,
      traces, and packetdrill test cases, which enabled us to root-cause
      this issue and verify the fix.
      
      - v1 -> v2:
       - In patch 2/3, changed an unclear comment in the pre-existing code
         in tcp_schedule_loss_probe() to be more clear (thanks to Eric Dumazet
         for suggesting we improve this).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      337f1b07
    • Neal Cardwell's avatar
      tcp: fix xmit timer to only be reset if data ACKed/SACKed · df92c839
      Neal Cardwell authored
      Fix a TCP loss recovery performance bug raised recently on the netdev
      list, in two threads:
      
      (i)  July 26, 2017: netdev thread "TCP fast retransmit issues"
      (ii) July 26, 2017: netdev thread:
           "[PATCH V2 net-next] TLP: Don't reschedule PTO when there's one
           outstanding TLP retransmission"
      
      The basic problem is that incoming TCP packets that did not indicate
      forward progress could cause the xmit timer (TLP or RTO) to be rearmed
      and pushed back in time. In certain corner cases this could result in
      the following problems noted in these threads:
      
       - Repeated ACKs coming in with bogus SACKs corrupted by middleboxes
         could cause TCP to repeatedly schedule TLPs forever. We kept
         sending TLPs after every ~200ms, which elicited bogus SACKs, which
         caused more TLPs, ad infinitum; we never fired an RTO to fill in
         the holes.
      
       - Incoming data segments could, in some cases, cause us to reschedule
         our RTO or TLP timer further out in time, for no good reason. This
         could cause repeated inbound data to result in stalls in outbound
         data, in the presence of packet loss.
      
      This commit fixes these bugs by changing the TLP and RTO ACK
      processing to:
      
       (a) Only reschedule the xmit timer once per ACK.
      
       (b) Only reschedule the xmit timer if tcp_clean_rtx_queue() deems the
           ACK indicates sufficient forward progress (a packet was
           cumulatively ACKed, or we got a SACK for a packet that was sent
           before the most recent retransmit of the write queue head).
      
      This brings us back into closer compliance with the RFCs, since, as
      the comment for tcp_rearm_rto() notes, we should only restart the RTO
      timer after forward progress on the connection. Previously we were
      restarting the xmit timer even in these cases where there was no
      forward progress.
      
      As a side benefit, this commit simplifies and speeds up the TCP timer
      arming logic. We had been calling inet_csk_reset_xmit_timer() three
      times on normal ACKs that cumulatively acknowledged some data:
      
      1) Once near the top of tcp_ack() to switch from TLP timer to RTO:
              if (icsk->icsk_pending == ICSK_TIME_LOSS_PROBE)
                     tcp_rearm_rto(sk);
      
      2) Once in tcp_clean_rtx_queue(), to update the RTO:
              if (flag & FLAG_ACKED) {
                     tcp_rearm_rto(sk);
      
      3) Once in tcp_ack() after tcp_fastretrans_alert() to switch from RTO
         to TLP:
              if (icsk->icsk_pending == ICSK_TIME_RETRANS)
                     tcp_schedule_loss_probe(sk);
      
      This commit, by only rescheduling the xmit timer once per ACK,
      simplifies the code and reduces CPU overhead.
      
      This commit was tested in an A/B test with Google web server
      traffic. SNMP stats and request latency metrics were within noise
      levels, substantiating that for normal web traffic patterns this is a
      rare issue. This commit was also tested with packetdrill tests to
      verify that it fixes the timer behavior in the corner cases discussed
      in the netdev threads mentioned above.
      
      This patch is a bug fix patch intended to be queued for -stable
      relases.
      
      Fixes: 6ba8a3b1 ("tcp: Tail loss probe (TLP)")
      Reported-by: default avatarKlavs Klavsen <kl@vsen.dk>
      Reported-by: default avatarMao Wenan <maowenan@huawei.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarNandita Dukkipati <nanditad@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df92c839
    • Neal Cardwell's avatar
      tcp: enable xmit timer fix by having TLP use time when RTO should fire · a2815817
      Neal Cardwell authored
      Have tcp_schedule_loss_probe() base the TLP scheduling decision based
      on when the RTO *should* fire. This is to enable the upcoming xmit
      timer fix in this series, where tcp_schedule_loss_probe() cannot
      assume that the last timer installed was an RTO timer (because we are
      no longer doing the "rearm RTO, rearm RTO, rearm TLP" dance on every
      ACK). So tcp_schedule_loss_probe() must independently figure out when
      an RTO would want to fire.
      
      In the new TLP implementation following in this series, we cannot
      assume that icsk_timeout was set based on an RTO; after processing a
      cumulative ACK the icsk_timeout we see can be from a previous TLP or
      RTO. So we need to independently recalculate the RTO time (instead of
      reading it out of icsk_timeout). Removing this dependency on the
      nature of icsk_timeout makes things a little easier to reason about
      anyway.
      
      Note that the old and new code should be equivalent, since they are
      both saying: "if the RTO is in the future, but at an earlier time than
      the normal TLP time, then set the TLP timer to fire when the RTO would
      have fired".
      
      Fixes: 6ba8a3b1 ("tcp: Tail loss probe (TLP)")
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarNandita Dukkipati <nanditad@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2815817
    • Neal Cardwell's avatar
      tcp: introduce tcp_rto_delta_us() helper for xmit timer fix · e1a10ef7
      Neal Cardwell authored
      Pure refactor. This helper will be required in the xmit timer fix
      later in the patch series. (Because the TLP logic will want to make
      this calculation.)
      
      Fixes: 6ba8a3b1 ("tcp: Tail loss probe (TLP)")
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarNandita Dukkipati <nanditad@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e1a10ef7
    • Xin Long's avatar
      ipv6: set rt6i_protocol properly in the route when it is installed · b91d5329
      Xin Long authored
      After commit c2ed1880 ("net: ipv6: check route protocol when
      deleting routes"), ipv6 route checks rt protocol when trying to
      remove a rt entry.
      
      It introduced a side effect causing 'ip -6 route flush cache' not
      to work well. When flushing caches with iproute, all route caches
      get dumped from kernel then removed one by one by sending DELROUTE
      requests to kernel for each cache.
      
      The thing is iproute sends the request with the cache whose proto
      is set with RTPROT_REDIRECT by rt6_fill_node() when kernel dumps
      it. But in kernel the rt_cache protocol is still 0, which causes
      the cache not to be matched and removed.
      
      So the real reason is rt6i_protocol in the route is not set when
      it is allocated. As David Ahern's suggestion, this patch is to
      set rt6i_protocol properly in the route when it is installed and
      remove the codes setting rtm_protocol according to rt6i_flags in
      rt6_fill_node.
      
      This is also an improvement to keep rt6i_protocol consistent with
      rtm_protocol.
      
      Fixes: c2ed1880 ("net: ipv6: check route protocol when deleting routes")
      Reported-by: default avatarJianlin Shi <jishi@redhat.com>
      Suggested-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b91d5329
    • Eric Dumazet's avatar
      net: fix keepalive code vs TCP_FASTOPEN_CONNECT · 2dda6400
      Eric Dumazet authored
      syzkaller was able to trigger a divide by 0 in TCP stack [1]
      
      Issue here is that keepalive timer needs to be updated to not attempt
      to send a probe if the connection setup was deferred using
      TCP_FASTOPEN_CONNECT socket option added in linux-4.11
      
      [1]
       divide error: 0000 [#1] SMP
       CPU: 18 PID: 0 Comm: swapper/18 Not tainted
       task: ffff986f62f4b040 ti: ffff986f62fa2000 task.ti: ffff986f62fa2000
       RIP: 0010:[<ffffffff8409cc0d>]  [<ffffffff8409cc0d>] __tcp_select_window+0x8d/0x160
       Call Trace:
        <IRQ>
        [<ffffffff8409d951>] tcp_transmit_skb+0x11/0x20
        [<ffffffff8409da21>] tcp_xmit_probe_skb+0xc1/0xe0
        [<ffffffff840a0ee8>] tcp_write_wakeup+0x68/0x160
        [<ffffffff840a151b>] tcp_keepalive_timer+0x17b/0x230
        [<ffffffff83b3f799>] call_timer_fn+0x39/0xf0
        [<ffffffff83b40797>] run_timer_softirq+0x1d7/0x280
        [<ffffffff83a04ddb>] __do_softirq+0xcb/0x257
        [<ffffffff83ae03ac>] irq_exit+0x9c/0xb0
        [<ffffffff83a04c1a>] smp_apic_timer_interrupt+0x6a/0x80
        [<ffffffff83a03eaf>] apic_timer_interrupt+0x7f/0x90
        <EOI>
        [<ffffffff83fed2ea>] ? cpuidle_enter_state+0x13a/0x3b0
        [<ffffffff83fed2cd>] ? cpuidle_enter_state+0x11d/0x3b0
      
      Tested:
      
      Following packetdrill no longer crashes the kernel
      
      `echo 0 >/proc/sys/net/ipv4/tcp_timestamps`
      
      // Cache warmup: send a Fast Open cookie request
          0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
         +0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
         +0 setsockopt(3, SOL_TCP, TCP_FASTOPEN_CONNECT, [1], 4) = 0
         +0 connect(3, ..., ...) = -1 EINPROGRESS (Operation is now in progress)
         +0 > S 0:0(0) <mss 1460,nop,nop,sackOK,nop,wscale 8,FO,nop,nop>
       +.01 < S. 123:123(0) ack 1 win 14600 <mss 1460,nop,nop,sackOK,nop,wscale 6,FO abcd1234,nop,nop>
         +0 > . 1:1(0) ack 1
         +0 close(3) = 0
         +0 > F. 1:1(0) ack 1
         +0 < F. 1:1(0) ack 2 win 92
         +0 > .  2:2(0) ack 2
      
         +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 4
         +0 fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
         +0 setsockopt(4, SOL_TCP, TCP_FASTOPEN_CONNECT, [1], 4) = 0
         +0 setsockopt(4, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
       +.01 connect(4, ..., ...) = 0
         +0 setsockopt(4, SOL_TCP, TCP_KEEPIDLE, [5], 4) = 0
         +10 close(4) = 0
      
      `echo 1 >/proc/sys/net/ipv4/tcp_timestamps`
      
      Fixes: 19f6d3f3 ("net/tcp-fastopen: Add new API support")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Wei Wang <weiwan@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2dda6400
    • David S. Miller's avatar
      Merge tag 'batadv-net-for-davem-20170802' of git://git.open-mesh.org/linux-merge · 4d2bbb0e
      David S. Miller authored
      Simon Wunderlich says:
      
      ====================
      Here is a batman-adv bugfix:
      
       - fix TT sync flag inconsistency problems, which can lead to excess packets,
         by Linus Luessing
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4d2bbb0e
  5. 02 Aug, 2017 7 commits