1. 24 Nov, 2018 2 commits
  2. 23 Nov, 2018 6 commits
    • Jason Wang's avatar
      virtio-net: fail XDP set if guest csum is negotiated · 18ba58e1
      Jason Wang authored
      We don't support partial csumed packet since its metadata will be lost
      or incorrect during XDP processing. So fail the XDP set if guest_csum
      feature is negotiated.
      
      Fixes: f600b690 ("virtio_net: Add XDP support")
      Reported-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Cc: Jesper Dangaard Brouer <brouer@redhat.com>
      Cc: Pavel Popa <pashinho1990@gmail.com>
      Cc: David Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      18ba58e1
    • Jason Wang's avatar
      virtio-net: disable guest csum during XDP set · e59ff2c4
      Jason Wang authored
      We don't disable VIRTIO_NET_F_GUEST_CSUM if XDP was set. This means we
      can receive partial csumed packets with metadata kept in the
      vnet_hdr. This may have several side effects:
      
      - It could be overridden by header adjustment, thus is might be not
        correct after XDP processing.
      - There's no way to pass such metadata information through
        XDP_REDIRECT to another driver.
      - XDP does not support checksum offload right now.
      
      So simply disable guest csum if possible in this the case of XDP.
      
      Fixes: 3f93522f ("virtio-net: switch off offloads on demand if possible on XDP set")
      Reported-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Cc: Jesper Dangaard Brouer <brouer@redhat.com>
      Cc: Pavel Popa <pashinho1990@gmail.com>
      Cc: David Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e59ff2c4
    • Davide Caratti's avatar
      net/sched: act_police: add missing spinlock initialization · 484afd1b
      Davide Caratti authored
      commit f2cbd485 ("net/sched: act_police: fix race condition on state
      variables") introduces a new spinlock, but forgets its initialization.
      Ensure that tcf_police_init() initializes 'tcfp_lock' every time a 'police'
      action is newly created, to avoid the following lockdep splat:
      
       INFO: trying to register non-static key.
       the code is fine but needs lockdep annotation.
       turning off the locking correctness validator.
       <...>
       Call Trace:
        dump_stack+0x85/0xcb
        register_lock_class+0x581/0x590
        __lock_acquire+0xd4/0x1330
        ? tcf_police_init+0x2fa/0x650 [act_police]
        ? lock_acquire+0x9e/0x1a0
        lock_acquire+0x9e/0x1a0
        ? tcf_police_init+0x2fa/0x650 [act_police]
        ? tcf_police_init+0x55a/0x650 [act_police]
        _raw_spin_lock_bh+0x34/0x40
        ? tcf_police_init+0x2fa/0x650 [act_police]
        tcf_police_init+0x2fa/0x650 [act_police]
        tcf_action_init_1+0x384/0x4c0
        tcf_action_init+0xf6/0x160
        tcf_action_add+0x73/0x170
        tc_ctl_action+0x122/0x160
        rtnetlink_rcv_msg+0x2a4/0x490
        ? netlink_deliver_tap+0x99/0x400
        ? validate_linkmsg+0x370/0x370
        netlink_rcv_skb+0x4d/0x130
        netlink_unicast+0x196/0x230
        netlink_sendmsg+0x2e5/0x3e0
        sock_sendmsg+0x36/0x40
        ___sys_sendmsg+0x280/0x2f0
        ? _raw_spin_unlock+0x24/0x30
        ? handle_pte_fault+0xafe/0xf30
        ? find_held_lock+0x2d/0x90
        ? syscall_trace_enter+0x1df/0x360
        ? __sys_sendmsg+0x5e/0xa0
        __sys_sendmsg+0x5e/0xa0
        do_syscall_64+0x60/0x210
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
       RIP: 0033:0x7f1841c7cf10
       Code: c3 48 8b 05 82 6f 2c 00 f7 db 64 89 18 48 83 cb ff eb dd 0f 1f 80 00 00 00 00 83 3d 8d d0 2c 00 00 75 10 b8 2e 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ae cc 00 00 48 89 04 24
       RSP: 002b:00007ffcf9df4d68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
       RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f1841c7cf10
       RDX: 0000000000000000 RSI: 00007ffcf9df4dc0 RDI: 0000000000000003
       RBP: 000000005bf56105 R08: 0000000000000002 R09: 00007ffcf9df8edc
       R10: 00007ffcf9df47e0 R11: 0000000000000246 R12: 0000000000671be0
       R13: 00007ffcf9df4e84 R14: 0000000000000008 R15: 0000000000000000
      
      Fixes: f2cbd485 ("net/sched: act_police: fix race condition on state variables")
      Reported-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      484afd1b
    • Paolo Abeni's avatar
      net: don't keep lonely packets forever in the gro hash · 605108ac
      Paolo Abeni authored
      Eric noted that with UDP GRO and NAPI timeout, we could keep a single
      UDP packet inside the GRO hash forever, if the related NAPI instance
      calls napi_gro_complete() at an higher frequency than the NAPI timeout.
      Willem noted that even TCP packets could be trapped there, till the
      next retransmission.
      This patch tries to address the issue, flushing the old packets -
      those with a NAPI_GRO_CB age before the current jiffy - before scheduling
      the NAPI timeout. The rationale is that such a timeout should be
      well below a jiffy and we are not flushing packets eligible for sane GRO.
      
      v1  -> v2:
       - clarified the commit message and comment
      
      RFC -> v1:
       - added 'Fixes tags', cleaned-up the wording.
      Reported-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Fixes: 3b47d303 ("net: gro: add a per device gro flush timer")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      605108ac
    • Hangbin Liu's avatar
      net/ipv6: re-do dad when interface has IFF_NOARP flag change · 896585d4
      Hangbin Liu authored
      When we add a new IPv6 address, we should also join corresponding solicited-node
      multicast address, unless the interface has IFF_NOARP flag, as function
      addrconf_join_solict() did. But if we remove IFF_NOARP flag later, we do
      not do dad and add the mcast address. So we will drop corresponding neighbour
      discovery message that came from other nodes.
      
      A typical example is after creating a ipvlan with mode l3, setting up an ipv6
      address and changing the mode to l2. Then we will not be able to ping this
      address as the interface doesn't join related solicited-node mcast address.
      
      Fix it by re-doing dad when interface changed IFF_NOARP flag. Then we will add
      corresponding mcast group and check if there is a duplicate address on the
      network.
      Reported-by: default avatarJianlin Shi <jishi@redhat.com>
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      896585d4
    • Willem de Bruijn's avatar
      packet: copy user buffers before orphan or clone · 5cd8d46e
      Willem de Bruijn authored
      tpacket_snd sends packets with user pages linked into skb frags. It
      notifies that pages can be reused when the skb is released by setting
      skb->destructor to tpacket_destruct_skb.
      
      This can cause data corruption if the skb is orphaned (e.g., on
      transmit through veth) or cloned (e.g., on mirror to another psock).
      
      Create a kernel-private copy of data in these cases, same as tun/tap
      zerocopy transmission. Reuse that infrastructure: mark the skb as
      SKBTX_ZEROCOPY_FRAG, which will trigger copy in skb_orphan_frags(_rx).
      
      Unlike other zerocopy packets, do not set shinfo destructor_arg to
      struct ubuf_info. tpacket_destruct_skb already uses that ptr to notify
      when the original skb is released and a timestamp is recorded. Do not
      change this timestamp behavior. The ubuf_info->callback is not needed
      anyway, as no zerocopy notification is expected.
      
      Mark destructor_arg as not-a-uarg by setting the lower bit to 1. The
      resulting value is not a valid ubuf_info pointer, nor a valid
      tpacket_snd frame address. Add skb_zcopy_.._nouarg helpers for this.
      
      The fix relies on features introduced in commit 52267790 ("sock:
      add MSG_ZEROCOPY"), so can be backported as is only to 4.14.
      
      Tested with from `./in_netns.sh ./txring_overwrite` from
      http://github.com/wdebruij/kerneltools/tests
      
      Fixes: 69e3c75f ("net: TX_RING and packet mmap")
      Reported-by: default avatarAnand H. Krishnan <anandhkrishnan@gmail.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5cd8d46e
  3. 22 Nov, 2018 12 commits
  4. 21 Nov, 2018 3 commits
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-for-davem-2018-11-20' of... · 1e2b1046
      David S. Miller authored
      Merge tag 'wireless-drivers-for-davem-2018-11-20' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for 4.20
      
      First set of fixes for 4.20, this time we have quite a few them but
      all very small.
      
      ath9k
      
      * fix a locking regression found by a static checker
      
      wlcore
      
      * fix a crash which was a regression with wakeirq handling
      
      brcm80211
      
      * yet another fix for 160 MHz channel handling
      
      mt76
      
      * fix a longstaning build problem when CONFIG_LEDS_CLASS is disabled
      
      * don't use uninitialised mutex
      
      iwlwifi
      
      * do note that the iwlwifi merge tag (commit 4ec321c1) seems to
        contain wrong list of changes so ignore that
      
      * fix ACPI data handling, a memory leak and other smaller fixes
      
      ath10k
      
      * fix a crash during suspend which was a recent regression
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1e2b1046
    • Eric Dumazet's avatar
      tcp: defer SACK compression after DupThresh · 86de5921
      Eric Dumazet authored
      Jean-Louis reported a TCP regression and bisected to recent SACK
      compression.
      
      After a loss episode (receiver not able to keep up and dropping
      packets because its backlog is full), linux TCP stack is sending
      a single SACK (DUPACK).
      
      Sender waits a full RTO timer before recovering losses.
      
      While RFC 6675 says in section 5, "Algorithm Details",
      
         (2) If DupAcks < DupThresh but IsLost (HighACK + 1) returns true --
             indicating at least three segments have arrived above the current
             cumulative acknowledgment point, which is taken to indicate loss
             -- go to step (4).
      ...
         (4) Invoke fast retransmit and enter loss recovery as follows:
      
      there are old TCP stacks not implementing this strategy, and
      still counting the dupacks before starting fast retransmit.
      
      While these stacks probably perform poorly when receivers implement
      LRO/GRO, we should be a little more gentle to them.
      
      This patch makes sure we do not enable SACK compression unless
      3 dupacks have been sent since last rcv_nxt update.
      
      Ideally we should even rearm the timer to send one or two
      more DUPACK if no more packets are coming, but that will
      be work aiming for linux-4.21.
      
      Many thanks to Jean-Louis for bisecting the issue, providing
      packet captures and testing this patch.
      
      Fixes: 5d9f4262 ("tcp: add SACK compression")
      Reported-by: default avatarJean-Louis Dupond <jean-louis@dupond.be>
      Tested-by: default avatarJean-Louis Dupond <jean-louis@dupond.be>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      86de5921
    • Petr Machata's avatar
      net: skb_scrub_packet(): Scrub offload_fwd_mark · b5dd186d
      Petr Machata authored
      When a packet is trapped and the corresponding SKB marked as
      already-forwarded, it retains this marking even after it is forwarded
      across veth links into another bridge. There, since it ingresses the
      bridge over veth, which doesn't have offload_fwd_mark, it triggers a
      warning in nbp_switchdev_frame_mark().
      
      Then nbp_switchdev_allowed_egress() decides not to allow egress from
      this bridge through another veth, because the SKB is already marked, and
      the mark (of 0) of course matches. Thus the packet is incorrectly
      blocked.
      
      Solve by resetting offload_fwd_mark() in skb_scrub_packet(). That
      function is called from tunnels and also from veth, and thus catches the
      cases where traffic is forwarded between bridges and transformed in a
      way that invalidates the marking.
      
      Fixes: 6bc506b4 ("bridge: switchdev: Add forward mark support for stacked devices")
      Fixes: abf4bb6b ("skbuff: Add the offload_mr_fwd_mark field")
      Signed-off-by: default avatarPetr Machata <petrm@mellanox.com>
      Suggested-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b5dd186d
  5. 20 Nov, 2018 9 commits
  6. 19 Nov, 2018 8 commits