1. 22 Nov, 2018 10 commits
  2. 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
  3. 20 Nov, 2018 9 commits
  4. 19 Nov, 2018 18 commits