1. 22 Aug, 2023 16 commits
  2. 21 Aug, 2023 19 commits
  3. 20 Aug, 2023 5 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