1. 23 Aug, 2023 1 commit
    • Sven Eckelmann's avatar
      wifi: ath11k: Don't drop tx_status when peer cannot be found · 400ece6c
      Sven Eckelmann authored
      When a station idles for a long time, hostapd will try to send a QoS Null
      frame to the station as "poll". NL80211_CMD_PROBE_CLIENT is used for this
      purpose. And the skb will be added to ack_status_frame - waiting for a
      completion via ieee80211_report_ack_skb().
      
      But when the peer was already removed before the tx_complete arrives, the
      peer will be missing. And when using dev_kfree_skb_any (instead of going
      through mac80211), the entry will stay inside ack_status_frames. This IDR
      will therefore run full after 8K request were generated for such clients.
      At this point, the access point will then just stall and not allow any new
      clients because idr_alloc() for ack_status_frame will fail.
      
      ieee80211_free_txskb() on the other hand will (when required) call
      ieee80211_report_ack_skb() and make sure that (when required) remove the
      entry from the ack_status_frame.
      
      Tested-on: IPQ6018 hw1.0 WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
      
      Fixes: 6257c702 ("wifi: ath11k: fix tx status reporting in encap offload mode")
      Fixes: 94739d45 ("ath11k: switch to using ieee80211_tx_status_ext()")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
      Link: https://lore.kernel.org/r/20230802-ath11k-ack_status_leak-v2-1-c0af729d6229@narfation.org
      400ece6c
  2. 22 Aug, 2023 7 commits
  3. 21 Aug, 2023 3 commits
  4. 20 Aug, 2023 12 commits
    • Furong Xu's avatar
      net: stmmac: Check more MAC HW features for XGMAC Core 3.20 · 669a5556
      Furong Xu authored
      1. XGMAC Core does not have hash_filter definition, it uses
      vlhash(VLAN Hash Filtering) instead, skip hash_filter when XGMAC.
      2. Show exact size of Hash Table instead of raw register value.
      3. Show full description of safety features defined by Synopsys Databook.
      4. When safety feature is configured with no parity, or ECC only,
      keep FSM Parity Checking disabled.
      Signed-off-by: default avatarFurong Xu <0x1207@gmail.com>
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      669a5556
    • David S. Miller's avatar
      Merge branch 'ipv6-update-route-when-delete-saddr' · 43bc9bd6
      David S. Miller authored
      Hangbin Liu says:
      
      ====================
      ipv6: update route when delete source address
      
      Currently, when remove an address, the IPv6 route will not remove the
      prefer source address when the address is bond to other device. Fix this
      issue and add related tests as Ido and David suggested.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      43bc9bd6
    • Hangbin Liu's avatar
      selftests: fib_test: add a test case for IPv6 source address delete · 429b55b4
      Hangbin Liu authored
      Add a test case for IPv6 source address delete.
      
      As David suggested, add tests:
      - Single device using src address
      - Two devices with the same source address
      - VRF with single device using src address
      - VRF with two devices using src address
      
      As Ido points out, in IPv6, the preferred source address is looked up in
      the same VRF as the first nexthop device. This will give us similar results
      to IPv4 if the route is installed in the same VRF as the nexthop device, but
      not when the nexthop device is enslaved to a different VRF. So add tests:
      - src address and nexthop dev in same VR
      - src address and nexthop device in different VRF
      
      The link local address delete logic is different from the global address.
      It should only affect the associate device it bonds to. So add tests cases
      for link local address testing.
      
      Here is the test result:
      
      IPv6 delete address route tests
          Single device using src address
          TEST: Prefsrc removed when src address removed on other device      [ OK ]
          Two devices with the same source address
          TEST: Prefsrc not removed when src address exist on other device    [ OK ]
          TEST: Prefsrc removed when src address removed on all devices       [ OK ]
          VRF with single device using src address
          TEST: Prefsrc removed when src address removed on other device      [ OK ]
          VRF with two devices using src address
          TEST: Prefsrc not removed when src address exist on other device    [ OK ]
          TEST: Prefsrc removed when src address removed on all devices       [ OK ]
          src address and nexthop dev in same VRF
          TEST: Prefsrc removed from VRF when source address deleted          [ OK ]
          TEST: Prefsrc in default VRF not removed                            [ OK ]
          TEST: Prefsrc not removed from VRF when source address exist        [ OK ]
          TEST: Prefsrc in default VRF removed                                [ OK ]
          src address and nexthop device in different VRF
          TEST: Prefsrc not removed from VRF when nexthop dev in diff VRF     [ OK ]
          TEST: Prefsrc not removed in default VRF                            [ OK ]
          TEST: Prefsrc removed from VRF when nexthop dev in diff VRF         [ OK ]
          TEST: Prefsrc removed in default VRF                                [ OK ]
          Table ID 0
          TEST: Prefsrc removed from default VRF when source address deleted  [ OK ]
          Link local source route
          TEST: Prefsrc not removed when delete ll addr from other dev        [ OK ]
          TEST: Prefsrc removed when delete ll addr                           [ OK ]
          TEST: Prefsrc not removed when delete ll addr from other dev        [ OK ]
          TEST: Prefsrc removed even ll addr still exist on other dev         [ OK ]
      
      Tests passed:  19
      Tests failed:   0
      Suggested-by: default avatarIdo Schimmel <idosch@idosch.org>
      Suggested-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      429b55b4
    • Hangbin Liu's avatar
      ipv6: do not match device when remove source route · b358f57f
      Hangbin Liu authored
      After deleting an IPv6 address on an interface and cleaning up the
      related preferred source entries, it is important to ensure that all
      routes associated with the deleted address are properly cleared. The
      current implementation of rt6_remove_prefsrc() only checks the preferred
      source addresses bound to the current device. However, there may be
      routes that are bound to other devices but still utilize the same
      preferred source address.
      
      To address this issue, it is necessary to also delete entries that are
      bound to other interfaces but share the same source address with the
      current device. Failure to delete these entries would leave routes that
      are bound to the deleted address unclear. Here is an example reproducer
      (I have omitted unrelated routes):
      
      + ip link add dummy1 type dummy
      + ip link add dummy2 type dummy
      + ip link set dummy1 up
      + ip link set dummy2 up
      + ip addr add 1:2:3:4::5/64 dev dummy1
      + ip route add 7:7:7:0::1 dev dummy1 src 1:2:3:4::5
      + ip route add 7:7:7:0::2 dev dummy2 src 1:2:3:4::5
      + ip -6 route show
      1:2:3:4::/64 dev dummy1 proto kernel metric 256 pref medium
      7:7:7::1 dev dummy1 src 1:2:3:4::5 metric 1024 pref medium
      7:7:7::2 dev dummy2 src 1:2:3:4::5 metric 1024 pref medium
      + ip addr del 1:2:3:4::5/64 dev dummy1
      + ip -6 route show
      7:7:7::1 dev dummy1 metric 1024 pref medium
      7:7:7::2 dev dummy2 src 1:2:3:4::5 metric 1024 pref medium
      
      As Ido reminds, in IPv6, the preferred source address is looked up in
      the same VRF as the first nexthop device, which is different with IPv4.
      So, while removing the device checking, we also need to add an
      ipv6_chk_addr() check to make sure the address does not exist on the other
      devices of the rt nexthop device's VRF.
      
      After fix:
      + ip addr del 1:2:3:4::5/64 dev dummy1
      + ip -6 route show
      7:7:7::1 dev dummy1 metric 1024 pref medium
      7:7:7::2 dev dummy2 metric 1024 pref medium
      Reported-by: default avatarThomas Haller <thaller@redhat.com>
      Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2170513Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b358f57f
    • Hangbin Liu's avatar
      selftests: vrf_route_leaking: remove ipv6_ping_frag from default testing · c4cf2bc0
      Hangbin Liu authored
      As the initial commit 1a017276 ("selftests: Add VRF route leaking
      tests") said, the IPv6 MTU test fails as source address selection
      picking ::1. Every time we run the selftest this one report failed.
      There seems not much meaning  to keep reporting a failure for 3 years
      that no one plan to fix/update. Let't just skip this one first. We can
      add it back when the issue fixed.
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c4cf2bc0
    • Patrick Rohr's avatar
      net: release reference to inet6_dev pointer · 5cb24968
      Patrick Rohr authored
      addrconf_prefix_rcv returned early without releasing the inet6_dev
      pointer when the PIO lifetime is less than accept_ra_min_lft.
      
      Fixes: 5027d54a ("net: change accept_ra_min_rtr_lft to affect all RA lifetimes")
      Cc: Maciej Żenczykowski <maze@google.com>
      Cc: Lorenzo Colitti <lorenzo@google.com>
      Cc: David Ahern <dsahern@kernel.org>
      Cc: Simon Horman <horms@kernel.org>
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Reviewed-by: default avatarMaciej Żenczykowski <maze@google.com>
      Signed-off-by: default avatarPatrick Rohr <prohr@google.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5cb24968
    • Eric Dumazet's avatar
      net: selectively purge error queue in IP_RECVERR / IPV6_RECVERR · 0f158b32
      Eric Dumazet authored
      Setting IP_RECVERR and IPV6_RECVERR options to zero currently
      purges the socket error queue, which was probably not expected
      for zerocopy and tx_timestamp users.
      
      I discovered this issue while preparing commit 6b5f43ea
      ("inet: move inet->recverr to inet->inet_flags"), I presume this
      change does not need to be backported to stable kernels.
      
      Add skb_errqueue_purge() helper to purge error messages only.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Cc: Soheil Hassas Yeganeh <soheil@google.com>
      Reviewed-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0f158b32
    • David S. Miller's avatar
      Merge branch 'fixed_phy_register-return-value' · 412a75dc
      David S. Miller authored
      Ruan Jinjie says:
      
      ====================
      net: Return PTR_ERR() for fixed_phy_register()
      
      fixed_phy_register() returns not only -EIO or -ENODEV, but also
      -EPROBE_DEFER, -EINVAL and -EBUSY. The Best practice is to return these
      error codes with PTR_ERR().
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      412a75dc
    • Ruan Jinjie's avatar
      net: lan743x: Return PTR_ERR() for fixed_phy_register() · 294f48e9
      Ruan Jinjie authored
      fixed_phy_register() returns -EPROBE_DEFER, -EINVAL and -EBUSY,
      etc, in addition to -EIO. The Best practice is to return these
      error codes with PTR_ERR().
      Signed-off-by: default avatarRuan Jinjie <ruanjinjie@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      294f48e9
    • Ruan Jinjie's avatar
      net: bcmgenet: Return PTR_ERR() for fixed_phy_register() · acf50d1a
      Ruan Jinjie authored
      fixed_phy_register() returns -EPROBE_DEFER, -EINVAL and -EBUSY,
      etc, in addition to -ENODEV. The Best practice is to return these
      error codes with PTR_ERR().
      Signed-off-by: default avatarRuan Jinjie <ruanjinjie@huawei.com>
      Acked-by: default avatarDoug Berger <opendmb@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      acf50d1a
    • Ruan Jinjie's avatar
      net: bgmac: Return PTR_ERR() for fixed_phy_register() · d6499f0b
      Ruan Jinjie authored
      fixed_phy_register() returns -EPROBE_DEFER, -EINVAL and -EBUSY,
      etc, in addition to -ENODEV. The best practice is to return
      these error codes with PTR_ERR().
      Signed-off-by: default avatarRuan Jinjie <ruanjinjie@huawei.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d6499f0b
    • Russell King (Oracle)'s avatar
      net: dsa: realtek: add phylink_get_caps implementation · b22eef68
      Russell King (Oracle) authored
      The user ports use RSGMII, but we don't have that, and DT doesn't
      specify a phy interface mode, so phylib defaults to GMII. These support
      1G, 100M and 10M with flow control. It is unknown whether asymetric
      pause is supported at all speeds.
      
      The CPU port uses MII/GMII/RGMII/REVMII by hardware pin strapping,
      and support speeds specific to each, with full duplex only supported
      in some modes. Flow control may be supported again by hardware pin
      strapping, and theoretically is readable through a register but no
      information is given in the datasheet for that.
      
      So, we do a best efforts - and be lenient.
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b22eef68
  5. 19 Aug, 2023 17 commits