* [PATCH 1/2] ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV
From: Vincent Chen @ 2026-04-29 6:51 UTC (permalink / raw)
To: anthony.l.nguyen, przemyslaw.kitszel
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, intel-wired-lan,
netdev, vincent.chen
In-Reply-To: <20260429065127.423949-1-vincent.chen@sifive.com>
Currently ice_eswitch_attach_vf() is called unconditionally in
ice_start_vfs(), which causes VF creation to fail when CONFIG_ICE_SWITCHDEV
is not defined.
Fix this by adding switchdev mode checks at the call sites before
calling ice_eswitch_attach_vf(), consistent with how
ice_eswitch_attach_sf() is already handled in ice_devlink_port_new().
This is similar to commit aacca7a83b97 ("ice: allow creating VFs for
!CONFIG_NET_SWITCHDEV") which fixed the same issue for the previous
ice_eswitch_configure() API.
Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
---
drivers/net/ethernet/intel/ice/ice_sriov.c | 14 ++++++++------
drivers/net/ethernet/intel/ice/ice_vf_lib.c | 3 ++-
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index 843e82fd3bf9..6a0b724e46f9 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -484,12 +484,14 @@ static int ice_start_vfs(struct ice_pf *pf)
goto teardown;
}
- retval = ice_eswitch_attach_vf(pf, vf);
- if (retval) {
- dev_err(ice_pf_to_dev(pf), "Failed to attach VF %d to eswitch, error %d",
- vf->vf_id, retval);
- ice_vf_vsi_release(vf);
- goto teardown;
+ if (ice_is_eswitch_mode_switchdev(pf)) {
+ retval = ice_eswitch_attach_vf(pf, vf);
+ if (retval) {
+ dev_err(ice_pf_to_dev(pf), "Failed to attach VF %d to eswitch, error %d",
+ vf->vf_id, retval);
+ ice_vf_vsi_release(vf);
+ goto teardown;
+ }
}
set_bit(ICE_VF_STATE_INIT, vf->vf_states);
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
index de9e81ccee66..71595410174c 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
@@ -807,7 +807,8 @@ void ice_reset_all_vfs(struct ice_pf *pf)
ice_vf_rebuild_vsi(vf);
ice_vf_post_vsi_rebuild(vf);
- ice_eswitch_attach_vf(pf, vf);
+ if (ice_is_eswitch_mode_switchdev(pf))
+ ice_eswitch_attach_vf(pf, vf);
mutex_unlock(&vf->cfg_lock);
}
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] ice: fix VF creation when !CONFIG_ICE_SWITCHDEV
From: Vincent Chen @ 2026-04-29 6:51 UTC (permalink / raw)
To: anthony.l.nguyen, przemyslaw.kitszel
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, intel-wired-lan,
netdev, vincent.chen
This patch series fixes an issue where VF creation fails when
CONFIG_ICE_SWITCHDEV is disabled.
When CONFIG_ICE_SWITCHDEV is disabled, the stub function
ice_eswitch_attach_vf() returns -EOPNOTSUPP, causing VF initialization to
fail even though basic VF functionality should work without switchdev
support.
The fix is split into two patches:
1. Add switchdev mode checks at caller sites to fix the immediate
issue while maintaining backward compatibility. This ensures
ice_eswitch_attach_vf() is only called when switchdev mode is
enabled, consistent with how ice_eswitch_attach_sf() is handled.
2. Remove the now-redundant internal switchdev check from
ice_eswitch_attach_vf().
Vincent Chen (2):
ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV
ice: remove redundant switchdev check in ice_eswitch_attach_vf()
drivers/net/ethernet/intel/ice/ice_eswitch.c | 3 ---
drivers/net/ethernet/intel/ice/ice_sriov.c | 14 ++++++++------
drivers/net/ethernet/intel/ice/ice_vf_lib.c | 3 ++-
3 files changed, 10 insertions(+), 10 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v2 net] sfc: fix error code in efx_devlink_info_running_versions()
From: Dan Carpenter @ 2026-04-29 6:48 UTC (permalink / raw)
To: Alejandro Lucero
Cc: Edward Cree, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Martin Habets, Jiri Pirko, netdev,
linux-net-drivers, linux-kernel, kernel-janitors
Return -EIO if efx_mcdi_rpc() doesn't return enough space.
Fixes: 14743ddd2495 ("sfc: add devlink info support for ef100")
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
v2: Originally I returned -EINVAL but -EIO is the usual error code
when 'MC response was too short'
---
drivers/net/ethernet/sfc/efx_devlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/efx_devlink.c b/drivers/net/ethernet/sfc/efx_devlink.c
index d842c60dfc10..e5c6f81af48b 100644
--- a/drivers/net/ethernet/sfc/efx_devlink.c
+++ b/drivers/net/ethernet/sfc/efx_devlink.c
@@ -531,7 +531,7 @@ static int efx_devlink_info_running_versions(struct efx_nic *efx,
if (rc || outlength < MC_CMD_GET_VERSION_OUT_LEN) {
netif_err(efx, drv, efx->net_dev,
"mcdi MC_CMD_GET_VERSION failed\n");
- return rc;
+ return rc ?: -EIO;
}
/* Handle previous output */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 00/18] Migrate rpcsec_gss_krb5 to the crypto/krb5 library
From: Jeff Layton @ 2026-04-29 6:39 UTC (permalink / raw)
To: Chuck Lever, Trond Myklebust, Anna Schumaker, Chuck Lever,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-nfs, netdev, linux-kernel, Herbert Xu, David Howells,
Simo Sorce
In-Reply-To: <20260427-crypto-krb5-api-v1-0-1fc1253b64c0@oracle.com>
On Mon, 2026-04-27 at 09:50 -0400, Chuck Lever wrote:
> The rpcsec_gss_krb5 module carries its own Kerberos 5 crypto imple-
> mentation: key derivation, CBC-CTS encryption, HMAC checksumming,
> and the encrypt-then-MAC construction from RFC 8009. Keeping
> cryptographic code inside an RPC module means it receives review
> only from the SUNRPC maintainers, who lack deep crypto expertise.
> Vulnerabilities and algorithmic errors can persist unnoticed.
>
> Replacing the private SunRPC Kerberos implementation eliminates
> this duplicated audit surface. A single implementation of Kerberos
> 5 key derivation and authenticated encryption is easier to verify
> than two independent copies. New encryption types and hardware
> offload added to crypto/krb5 will automatically become available
> to SunRPC Kerberos consumers.
>
> The crypto/krb5 library handles enctype differences internally, so
> a single encrypt function and a single decrypt function serve all
> enctypes, eliminating the per-enctype dispatch table that previously
> existed in struct gss_krb5_enctype.
>
> RFC 4121 Section 4.2.4 requires MIC checksums to cover the message
> body followed by the GSS token header. The crypto/krb5 get_mic/
> verify_mic API hashes optional metadata before the scatterlist
> data, which is the wrong order for the GSS header. The header is
> therefore placed at the end of the scatterlist rather than passed
> as the metadata parameter, and a dedicated gss_krb5_mic_build_sg()
> helper constructs this three-section layout (checksum area, message
> body, token header) with proper sg_mark_end() termination.
>
> This implementation was available during the Spring 2026 NFS bake-
> a-thon, and received testing there.
>
> ---
> Chuck Lever (18):
> SUNRPC: Add Kconfig dependency on CRYPTO_KRB5
> SUNRPC: Add crypto/krb5 enctype lookup to krb5_ctx
> SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists
> SUNRPC: Add errno-to-GSS status conversion helper
> SUNRPC: Prepare crypto/krb5 encryption and checksum handles
> SUNRPC: Switch wrap token encryption to crypto/krb5
> SUNRPC: Switch wrap token decryption to crypto/krb5
> SUNRPC: Switch Camellia decrypt to crypto/krb5
> SUNRPC: Switch MIC token generation to crypto/krb5
> SUNRPC: Switch MIC token verification to crypto/krb5
> SUNRPC: Remove get_mic/verify_mic function pointers from enctype table
> SUNRPC: Remove wrap/unwrap function pointers from enctype table
> SUNRPC: Remove encrypt/decrypt function pointers from enctype table
> SUNRPC: Remove legacy skcipher/ahash handles from krb5_ctx
> SUNRPC: Remove dead code from rpcsec_gss_krb5
> SUNRPC: Remove per-enctype Kconfig options
> SUNRPC: Remove redundant crypto Kconfig dependencies
> SUNRPC: Remove dead rpcsec_gss_krb5 definitions
>
> include/linux/sunrpc/gss_krb5.h | 105 --
> include/linux/sunrpc/xdr.h | 16 +-
> net/sunrpc/.kunitconfig | 29 -
> net/sunrpc/Kconfig | 56 +-
> net/sunrpc/auth_gss/Makefile | 4 +-
> net/sunrpc/auth_gss/gss_krb5_crypto.c | 1014 ++++-------------
> net/sunrpc/auth_gss/gss_krb5_internal.h | 155 +--
> net/sunrpc/auth_gss/gss_krb5_keys.c | 546 ---------
> net/sunrpc/auth_gss/gss_krb5_mech.c | 441 ++------
> net/sunrpc/auth_gss/gss_krb5_seal.c | 47 +-
> net/sunrpc/auth_gss/gss_krb5_test.c | 1868 -------------------------------
> net/sunrpc/auth_gss/gss_krb5_unseal.c | 36 +-
> net/sunrpc/auth_gss/gss_krb5_wrap.c | 13 +-
> net/sunrpc/xdr.c | 266 +++--
> 14 files changed, 573 insertions(+), 4023 deletions(-)
> ---
> base-commit: f3a96328282e8d41ba9f478d24ac122e4cbd2989
> change-id: 20260316-crypto-krb5-api-b9ee22636698
>
> Best regards,
> --
> Chuck Lever
Love that diffstat. Nice work!
One comment in general: Do you need to add Assisted-by: tags to any of
this? You can add this to the set:
Reviewed-by: Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH ipsec 0/3] xfrm: Don't clobber inner headers when already set
From: Steffen Klassert @ 2026-04-29 6:32 UTC (permalink / raw)
To: Cosmin Ratiu
Cc: netdev, Herbert Xu, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Andrew Lunn,
Shuah Khan, Nimrod Oren, Carolina Jubran, Gal Pressman,
linux-kselftest
In-Reply-To: <20260422140648.3877129-1-cratiu@nvidia.com>
On Wed, Apr 22, 2026 at 05:06:45PM +0300, Cosmin Ratiu wrote:
> Commit [1] exposed an existing issue in xfrm which broke tunneling
> protocols over IPsec (e.g. VXLAN over IPsec).
>
> This series fixes that and adds a test which exercises VXLAN over IPsec.
> For details please see the individual patches.
>
> [1] commit 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()")
>
> Cosmin Ratiu (3):
> tools/selftests: Use a sensible timeout value for iperf3 client
> tools/selftests: Add a VXLAN+IPsec traffic test
> xfrm: Don't clobber inner headers when already set
Series applied, thanks a lot Cosmin!
^ permalink raw reply
* [PATCH net-next 2/2] selftests: net: Add tests for ARP probe and DAD NS handling
From: Danielle Ratson @ 2026-04-29 6:24 UTC (permalink / raw)
To: netdev
Cc: razor, idosch, davem, edumazet, kuba, pabeni, horms, shuah,
bridge, linux-kernel, linux-kselftest, Danielle Ratson
In-Reply-To: <20260429062405.1386417-1-danieller@nvidia.com>
Add test cases to verify that ARP probes and DAD Neighbor Solicitations
are handled correctly by the bridge neighbor suppression feature.
When neighbor suppression is enabled on a bridge VXLAN port, the bridge
should reply to ARP/NS messages on behalf of remote hosts when both FDB
and neighbor entries exist, and the answer is known. However, when
either the FDB or the neighbor exists, ARP probes / DAD NS should be
treated like regular ARP requests / NS and flood to VXLAN.
Add two new test functions:
neigh_suppress_arp_probe(): Tests ARP probe handling by triggering
duplicate address detection using arping -D. Verifies that probes are
flooded when the bridge doesn't know the answer, and suppressed when FDB
and neighbor entries exist.
neigh_suppress_dad_ns(): Tests DAD NS handling by constructing DAD NS
packets using mausezahn and verifies correct flooding/suppression
behavior.
Before the previous patch:
$ ./test_bridge_neigh_suppress.sh -t "neigh_suppress_arp_probe neigh_suppress_dad_ns"
Per-port ARP probe suppression
------------------------------
TEST: ARP probe suppression [ OK ]
TEST: "neigh_suppress" is on [ OK ]
TEST: ARP probe suppression [FAIL]
TEST: FDB and neighbor entry installation [ OK ]
TEST: arping [FAIL]
TEST: ARP probe suppression [FAIL]
TEST: neighbor removal [ OK ]
TEST: ARP probe suppression [FAIL]
TEST: "neigh_suppress" is off [ OK ]
TEST: ARP probe suppression [FAIL]
Per-port DAD NS suppression
---------------------------
TEST: DAD NS suppression [ OK ]
TEST: "neigh_suppress" is on [ OK ]
TEST: DAD NS suppression [FAIL]
TEST: FDB and neighbor entry installation [ OK ]
TEST: DAD NS suppression [FAIL]
TEST: neighbor removal [ OK ]
TEST: DAD NS suppression [FAIL]
TEST: DAD NS proxy NA reply [FAIL]
TEST: "neigh_suppress" is off [ OK ]
TEST: DAD NS suppression [FAIL]
Tests passed: 10
Tests failed: 10
After the previous patch:
$ ./test_bridge_neigh_suppress.sh -t "neigh_suppress_arp_probe neigh_suppress_dad_ns"
Per-port ARP probe suppression
------------------------------
TEST: ARP probe suppression [ OK ]
TEST: "neigh_suppress" is on [ OK ]
TEST: ARP probe suppression [ OK ]
TEST: FDB and neighbor entry installation [ OK ]
TEST: arping [ OK ]
TEST: ARP probe suppression [ OK ]
TEST: neighbor removal [ OK ]
TEST: ARP probe suppression [ OK ]
TEST: "neigh_suppress" is off [ OK ]
TEST: ARP probe suppression [ OK ]
Per-port DAD NS suppression
---------------------------
TEST: DAD NS suppression [ OK ]
TEST: "neigh_suppress" is on [ OK ]
TEST: DAD NS suppression [ OK ]
TEST: FDB and neighbor entry installation [ OK ]
TEST: DAD NS suppression [ OK ]
TEST: neighbor removal [ OK ]
TEST: DAD NS suppression [ OK ]
TEST: DAD NS proxy NA reply [ OK ]
TEST: "neigh_suppress" is off [ OK ]
TEST: DAD NS suppression [ OK ]
Tests passed: 20
Tests failed: 0
Signed-off-by: Danielle Ratson <danieller@nvidia.com>
---
.../net/test_bridge_neigh_suppress.sh | 126 ++++++++++++++++++
1 file changed, 126 insertions(+)
diff --git a/tools/testing/selftests/net/test_bridge_neigh_suppress.sh b/tools/testing/selftests/net/test_bridge_neigh_suppress.sh
index 9067197c9055..4bc92078e173 100755
--- a/tools/testing/selftests/net/test_bridge_neigh_suppress.sh
+++ b/tools/testing/selftests/net/test_bridge_neigh_suppress.sh
@@ -56,6 +56,8 @@ TESTS="
neigh_suppress_uc_ns
neigh_vlan_suppress_arp
neigh_vlan_suppress_ns
+ neigh_suppress_arp_probe
+ neigh_suppress_dad_ns
"
VERBOSE=0
PAUSE_ON_FAIL=no
@@ -875,6 +877,130 @@ neigh_vlan_suppress_ns()
log_test $? 0 "NS suppression (VLAN $vid2)"
}
+neigh_suppress_arp_probe()
+{
+ local vid=10
+ local tip=192.0.2.2
+ local h2_mac
+
+ echo
+ echo "Per-port ARP probe suppression"
+ echo "------------------------------"
+
+ run_cmd "tc -n $sw1 qdisc replace dev vx0 clsact"
+ run_cmd "tc -n $sw1 filter replace dev vx0 egress pref 1 handle 101 proto 0x0806 flower indev swp1 arp_tip $tip arp_sip 0.0.0.0 arp_op request action pass"
+
+ # Initial state - check that ARP probes are not suppressed.
+ run_cmd "ip netns exec $h1 arping -D -q -c 1 -w 5 -I eth0.$vid $tip"
+ tc_check_packets "$sw1" "dev vx0 egress" 101 1
+ log_test $? 0 "ARP probe suppression"
+
+ # Enable neighbor suppression and check that nothing changes.
+ run_cmd "bridge -n $sw1 link set dev vx0 neigh_suppress on"
+ run_cmd "bridge -n $sw1 -d link show dev vx0 | grep \"neigh_suppress on\""
+ log_test $? 0 "\"neigh_suppress\" is on"
+
+ run_cmd "ip netns exec $h1 arping -D -q -c 1 -w 5 -I eth0.$vid $tip"
+ tc_check_packets "$sw1" "dev vx0 egress" 101 2
+ log_test $? 0 "ARP probe suppression"
+
+ # Install FDB and a neighbor and check that ARP probes are suppressed.
+ h2_mac=$(ip -n "$h2" -j -p link show eth0."$vid" | jq -r '.[]["address"]')
+ run_cmd "bridge -n $sw1 fdb replace $h2_mac dev vx0 master static vlan $vid"
+ run_cmd "ip -n $sw1 neigh replace $tip lladdr $h2_mac nud permanent dev br0.$vid"
+ log_test $? 0 "FDB and neighbor entry installation"
+
+ run_cmd "ip netns exec $h1 arping -D -q -c 1 -w 5 -I eth0.$vid $tip"
+ log_test $? 1 "arping"
+ tc_check_packets "$sw1" "dev vx0 egress" 101 2
+ log_test $? 0 "ARP probe suppression"
+
+ # Remove the neighbor entry and check that ARP probes are not suppressed.
+ run_cmd "ip -n $sw1 neigh del $tip dev br0.$vid"
+ log_test $? 0 "neighbor removal"
+
+ run_cmd "ip netns exec $h1 arping -D -q -c 1 -w 5 -I eth0.$vid $tip"
+ tc_check_packets "$sw1" "dev vx0 egress" 101 3
+ log_test $? 0 "ARP probe suppression"
+
+ # Disable neighbor suppression.
+ run_cmd "bridge -n $sw1 link set dev vx0 neigh_suppress off"
+ run_cmd "bridge -n $sw1 -d link show dev vx0 | grep \"neigh_suppress off\""
+ log_test $? 0 "\"neigh_suppress\" is off"
+
+ run_cmd "ip netns exec $h1 arping -D -q -c 1 -w 5 -I eth0.$vid $tip"
+ tc_check_packets "$sw1" "dev vx0 egress" 101 4
+ log_test $? 0 "ARP probe suppression"
+}
+
+neigh_suppress_dad_ns()
+{
+ local vid=10
+ local tip=2001:db8:1::99
+ local mcast=ff02::1:ff00:99
+ local dmac=33:33:ff:00:00:99
+ local full_tip=20:01:0d:b8:00:01:00:00:00:00:00:00:00:00:00:99
+ local csum="4b:bc"
+ local smac
+ local tmac
+
+ echo
+ echo "Per-port DAD NS suppression"
+ echo "---------------------------"
+
+ smac=$(ip -n "$h1" -j -p link show eth0."$vid" | jq -r '.[]["address"]')
+
+ run_cmd "tc -n $sw1 qdisc replace dev vx0 clsact"
+ run_cmd "tc -n $sw1 filter replace dev vx0 egress pref 1 handle 101 proto ipv6 flower indev swp1 ip_proto icmpv6 dst_ip $mcast src_ip :: type 135 code 0 action pass"
+
+ # Initial state - check that DAD NS are not suppressed.
+ run_cmd "ip netns exec $h1 mausezahn -6 eth0.$vid -c 1 -a $smac -b $dmac -A :: -B $mcast -t ip hop=255,next=58,payload=$(icmpv6_header_get "$csum" "$full_tip") -q"
+ tc_check_packets "$sw1" "dev vx0 egress" 101 1
+ log_test $? 0 "DAD NS suppression"
+
+ # Enable neighbor suppression and check that nothing changes.
+ run_cmd "bridge -n $sw1 link set dev vx0 neigh_suppress on"
+ run_cmd "bridge -n $sw1 -d link show dev vx0 | grep \"neigh_suppress on\""
+ log_test $? 0 "\"neigh_suppress\" is on"
+
+ run_cmd "ip netns exec $h1 mausezahn -6 eth0.$vid -c 1 -a $smac -b $dmac -A :: -B $mcast -t ip hop=255,next=58,payload=$(icmpv6_header_get "$csum" "$full_tip") -q"
+ tc_check_packets "$sw1" "dev vx0 egress" 101 2
+ log_test $? 0 "DAD NS suppression"
+
+ # Install FDB and a neighbor and check that DAD NS are suppressed
+ # and that a proxy NA is sent back to h1.
+ tmac=$(ip -n "$h2" -j -p link show eth0."$vid" | jq -r '.[]["address"]')
+ run_cmd "bridge -n $sw1 fdb replace $tmac dev vx0 master static vlan $vid"
+ run_cmd "ip -n $sw1 -6 neigh replace $tip lladdr $tmac nud permanent dev br0.$vid"
+ log_test $? 0 "FDB and neighbor entry installation"
+
+ run_cmd "tc -n $h1 qdisc replace dev eth0.$vid clsact"
+ run_cmd "tc -n $h1 filter replace dev eth0.$vid ingress pref 1 handle 101 proto ipv6 flower ip_proto icmpv6 dst_ip ff02::1 src_ip $tip type 136 code 0 action pass"
+
+ run_cmd "ip netns exec $h1 mausezahn -6 eth0.$vid -c 1 -a $smac -b $dmac -A :: -B $mcast -t ip hop=255,next=58,payload=$(icmpv6_header_get "$csum" "$full_tip") -q"
+ tc_check_packets "$sw1" "dev vx0 egress" 101 2
+ log_test $? 0 "DAD NS suppression"
+ tc_check_packets "$h1" "dev eth0.$vid ingress" 101 1
+ log_test $? 0 "DAD NS proxy NA reply"
+
+ # Remove the neighbor entry and check that DAD NS are not suppressed.
+ run_cmd "ip -n $sw1 -6 neigh del $tip dev br0.$vid"
+ log_test $? 0 "neighbor removal"
+
+ run_cmd "ip netns exec $h1 mausezahn -6 eth0.$vid -c 1 -a $smac -b $dmac -A :: -B $mcast -t ip hop=255,next=58,payload=$(icmpv6_header_get "$csum" "$full_tip") -q"
+ tc_check_packets "$sw1" "dev vx0 egress" 101 3
+ log_test $? 0 "DAD NS suppression"
+
+ # Disable neighbor suppression.
+ run_cmd "bridge -n $sw1 link set dev vx0 neigh_suppress off"
+ run_cmd "bridge -n $sw1 -d link show dev vx0 | grep \"neigh_suppress off\""
+ log_test $? 0 "\"neigh_suppress\" is off"
+
+ run_cmd "ip netns exec $h1 mausezahn -6 eth0.$vid -c 1 -a $smac -b $dmac -A :: -B $mcast -t ip hop=255,next=58,payload=$(icmpv6_header_get "$csum" "$full_tip") -q"
+ tc_check_packets "$sw1" "dev vx0 egress" 101 4
+ log_test $? 0 "DAD NS suppression"
+}
+
################################################################################
# Usage
--
2.51.0
^ permalink raw reply related
* [PATCH net-next 1/2] bridge: Do not suppress ARP probes and DAD NS unconditionally
From: Danielle Ratson @ 2026-04-29 6:24 UTC (permalink / raw)
To: netdev
Cc: razor, idosch, davem, edumazet, kuba, pabeni, horms, shuah,
bridge, linux-kernel, linux-kselftest, Danielle Ratson
In-Reply-To: <20260429062405.1386417-1-danieller@nvidia.com>
When neighbor suppression is enabled on a VXLAN port, the bridge is
expected to reply to ARP/NS messages on behalf of remote hosts when both
FDB and neighbor entries exist. This allows the bridge to suppress
flooding of these messages to the VXLAN overlay.
According to RFC 9161 ("Operational Aspects of Proxy ARP/ND in Ethernet
Virtual Private Networks"):
"A PE SHOULD reply to broadcast/multicast address resolution messages,
i.e., ARP Requests, ARP probes, NS messages, as well as DAD NS messages.
An ARP probe is an ARP Request constructed with an all-zero sender IP
address that may be used by hosts for IPv4 Address Conflict Detection as
specified in [RFC5227]".
However, the current implementation unconditionally suppresses ARP probes
and DAD Neighbor Solicitations, which breaks Duplicate Address Detection
(DAD) over EVPN.
For DAD to work correctly over the VXLAN fabric:
- When the bridge does not know the answer:
flood the probe/DAD packet to allow remote VTEPs to respond.
- When the bridge knows the answer:
reply to indicate the address is in use.
Fix by adjusting the early suppression checks to exclude ARP probes and
DAD NS from unconditional suppression.
When replying to a DAD NS, br_nd_send() is adjusted to set the NA
destination to the all-nodes multicast address (ff02::1) and clear the
Solicited flag, in accordance with RFC 4861 section 7.2.4.
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Danielle Ratson <danieller@nvidia.com>
---
net/bridge/br_arp_nd_proxy.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/net/bridge/br_arp_nd_proxy.c b/net/bridge/br_arp_nd_proxy.c
index deb1ab1f24b0..3205346f298c 100644
--- a/net/bridge/br_arp_nd_proxy.c
+++ b/net/bridge/br_arp_nd_proxy.c
@@ -164,7 +164,7 @@ void br_do_proxy_suppress_arp(struct sk_buff *skb, struct net_bridge *br,
return;
if (parp->ar_op != htons(ARPOP_RREQUEST) &&
parp->ar_op != htons(ARPOP_RREPLY) &&
- (ipv4_is_zeronet(sip) || sip == tip)) {
+ sip == tip) {
/* prevent flooding to neigh suppress ports */
BR_INPUT_SKB_CB(skb)->proxyarp_replied = 1;
return;
@@ -262,6 +262,7 @@ static void br_nd_send(struct net_bridge *br, struct net_bridge_port *p,
int ns_olen;
int i, len;
u8 *daddr;
+ bool dad;
u16 pvid;
if (!dev || skb_linearize(request))
@@ -300,8 +301,13 @@ static void br_nd_send(struct net_bridge *br, struct net_bridge_port *p,
}
}
+ dad = ipv6_addr_any(&ipv6_hdr(request)->saddr);
+
/* Ethernet header */
- ether_addr_copy(eth_hdr(reply)->h_dest, daddr);
+ if (dad)
+ ipv6_eth_mc_map(&in6addr_linklocal_allnodes, eth_hdr(reply)->h_dest);
+ else
+ ether_addr_copy(eth_hdr(reply)->h_dest, daddr);
ether_addr_copy(eth_hdr(reply)->h_source, n->ha);
eth_hdr(reply)->h_proto = htons(ETH_P_IPV6);
reply->protocol = htons(ETH_P_IPV6);
@@ -317,7 +323,7 @@ static void br_nd_send(struct net_bridge *br, struct net_bridge_port *p,
pip6->priority = ipv6_hdr(request)->priority;
pip6->nexthdr = IPPROTO_ICMPV6;
pip6->hop_limit = 255;
- pip6->daddr = ipv6_hdr(request)->saddr;
+ pip6->daddr = dad ? in6addr_linklocal_allnodes : ipv6_hdr(request)->saddr;
pip6->saddr = *(struct in6_addr *)n->primary_key;
skb_pull(reply, sizeof(struct ipv6hdr));
@@ -330,7 +336,7 @@ static void br_nd_send(struct net_bridge *br, struct net_bridge_port *p,
na->icmph.icmp6_type = NDISC_NEIGHBOUR_ADVERTISEMENT;
na->icmph.icmp6_router = (n->flags & NTF_ROUTER) ? 1 : 0;
na->icmph.icmp6_override = 1;
- na->icmph.icmp6_solicited = 1;
+ na->icmph.icmp6_solicited = dad ? 0 : 1;
na->target = ns->target;
ether_addr_copy(&na->opt[2], n->ha);
na->opt[0] = ND_OPT_TARGET_LL_ADDR;
@@ -435,7 +441,7 @@ void br_do_suppress_nd(struct sk_buff *skb, struct net_bridge *br,
saddr = &iphdr->saddr;
daddr = &iphdr->daddr;
- if (ipv6_addr_any(saddr) || !ipv6_addr_cmp(saddr, daddr)) {
+ if (!ipv6_addr_cmp(saddr, daddr)) {
/* prevent flooding to neigh suppress ports */
BR_INPUT_SKB_CB(skb)->proxyarp_replied = 1;
return;
--
2.51.0
^ permalink raw reply related
* [PATCH net-next 0/2] bridge: Do not suppress ARP probes and DAD NS unconditionally
From: Danielle Ratson @ 2026-04-29 6:24 UTC (permalink / raw)
To: netdev
Cc: razor, idosch, davem, edumazet, kuba, pabeni, horms, shuah,
bridge, linux-kernel, linux-kselftest, Danielle Ratson
When using bridge neighbor suppression in EVPN deployments, Duplicate
Address Detection (DAD) is currently broken for both IPv4 (ARP probes)
and IPv6 (DAD Neighbor Solicitations). This prevents proper address
conflict detection across the VXLAN fabric.
The neighbor suppression feature allows the bridge to reply to ARP/NS
messages on behalf of remote hosts when FDB and neighbor entries exist,
suppressing unnecessary flooding over the VXLAN overlay. However, the
current implementation unconditionally suppresses ARP probes and DAD NS,
which breaks DAD.
For DAD to work correctly:
- When the bridge doesn't know the answer:
flood the probe/DAD packet to allow remote VTEPs to respond.
- When the bridge knows the answer:
reply to indicate the address is in use.
This series fixes the issue by adjusting the early suppression checks to
exclude ARP probes and DAD NS from unconditional suppression, allowing
them to reach the normal FDB lookup path. Gratuitous ARP and IPv6
unsolicited-NA messages are still suppressed unconditionally as before.
Patchset overview:
Patch #1: Fixes the unconditional suppression.
Patch #2: Adds selftests.
Danielle Ratson (2):
bridge: Do not suppress ARP probes and DAD NS unconditionally
selftests: net: Add tests for ARP probe and DAD NS handling
net/bridge/br_arp_nd_proxy.c | 16 ++-
.../net/test_bridge_neigh_suppress.sh | 126 ++++++++++++++++++
2 files changed, 137 insertions(+), 5 deletions(-)
--
2.51.0
^ permalink raw reply
* [PATCH] net: stmmac: Use interrupt mode INTM=1 for per channel irq
From: muhammad.nazim.amirul.nazle.asmade @ 2026-04-29 6:24 UTC (permalink / raw)
To: netdev; +Cc: davem, kuba, pabeni, edumazet, andrew+netdev, linux-kernel
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
commit 6ccf12ae111e ("net: stmmac: use interrupt mode INTM=1 for
multi-MSI") introduced INTM=1 interrupt mode for platforms using MSI.
Apply a similar approach to enable per-channel interrupts using shared
peripheral interrupt (SPI), so that only per-channel TX and RX
interrupts (TI/RI) are handled by the TX/RX ISR without invoking the
common interrupt ISR.
The TX/RX NORMAL interrupt check is decoupled since the NIS bit is not
asserted for TI/RI events when INTM=1.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 3 +++
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 7 +++++++
include/linux/stmmac.h | 6 ++++++
3 files changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index 51943705a2b0..94cbf24b3118 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -320,6 +320,9 @@
/* DMA Registers */
#define XGMAC_DMA_MODE 0x00003000
#define XGMAC_SWR BIT(0)
+#define DMA_MODE_INTM_MASK GENMASK(13, 12)
+#define DMA_MODE_INTM_SHIFT 12
+#define DMA_MODE_INTM_MODE1 0x1
#define XGMAC_DMA_SYSBUS_MODE 0x00003004
#define XGMAC_WR_OSR_LMT GENMASK(29, 24)
#define XGMAC_RD_OSR_LMT GENMASK(21, 16)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
index 03437f1cf3df..3789b62cd2e3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
@@ -31,6 +31,13 @@ static void dwxgmac2_dma_init(void __iomem *ioaddr,
value |= XGMAC_EAME;
writel(value, ioaddr + XGMAC_DMA_SYSBUS_MODE);
+
+ if (dma_cfg->multi_irq_en) {
+ value = readl(ioaddr + XGMAC_DMA_MODE);
+ value &= ~DMA_MODE_INTM_MASK;
+ value |= (DMA_MODE_INTM_MODE1 << DMA_MODE_INTM_SHIFT);
+ writel(value, ioaddr + XGMAC_DMA_MODE);
+ }
}
static void dwxgmac2_dma_init_chan(struct stmmac_priv *priv,
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 4430b967abde..5deaa1a797a5 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -122,6 +122,7 @@ struct stmmac_dma_cfg {
bool eame;
/* multi_msi_en: stmmac core internal */
bool multi_msi_en;
+ bool multi_irq_en;
/* atds: stmmac core internal */
bool atds;
};
@@ -349,6 +350,11 @@ struct plat_stmmacenet_data {
u8 vlan_fail_q;
bool provide_bus_info;
int int_snapshot_num;
+ int ext_snapshot_num;
+ bool int_snapshot_en;
+ bool ext_snapshot_en;
+ bool multi_msi_en;
+ bool multi_irq_en;
int msi_mac_vec;
int msi_wol_vec;
int msi_sfty_ce_vec;
--
2.43.7
^ permalink raw reply related
* Re: [PATCH 1/2] net: thunderbolt: Call tbnet_stop() upon shutdown
From: Mika Westerberg @ 2026-04-29 5:30 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, YehezkelShB, andrew+netdev, davem, edumazet, pabeni
In-Reply-To: <20260429011224.1505785-1-kuba@kernel.org>
On Tue, Apr 28, 2026 at 06:12:24PM -0700, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net: thunderbolt: Call tbnet_stop() upon shutdown
>
> This commit updates the shutdown callback for the Thunderbolt network service
> driver to call tbnet_stop() if the interface is running. This ensures the
> service drivers release the rings upon shutdown.
>
> > diff --git a/drivers/net/thunderbolt/main.c b/drivers/net/thunderbolt/main.c
> > index 7aae5d915a1e..631af237998d 100644
> > --- a/drivers/net/thunderbolt/main.c
> > +++ b/drivers/net/thunderbolt/main.c
> > @@ -1417,7 +1417,10 @@ static void tbnet_remove(struct tb_service *svc)
> >
> > static void tbnet_shutdown(struct tb_service *svc)
> > {
> > - tbnet_tear_down(tb_service_get_drvdata(svc), true);
> > + struct tbnet *net = tb_service_get_drvdata(svc);
> > +
> > + if (netif_running(net->dev))
> > + tbnet_stop(net->dev);
>
> Does calling tbnet_stop() directly bypass the network stack teardown sequence?
This is called when the machine is rebooted or shut down to quiesce the
device. I don't think the network stack has anything similar?
> tbnet_stop() appears to be the driver's ndo_stop callback. By bypassing
> dev_close(), netif_tx_disable() is not called and the device's transmit queues
> remain active.
tbnet_stop() calls tbnet_tear_down() that calls netif_stop_queue() which
should stop the queue.
> tbnet_stop() destroys the DMA rings and explicitly sets net->tx_ring.ring
> to NULL:
>
> drivers/net/thunderbolt/main.c:tbnet_stop() {
> ...
> tb_ring_free(net->tx_ring.ring);
> net->tx_ring.ring = NULL;
> ...
> }
>
> If a concurrent transmission occurs, will tbnet_start_xmit() access the null
> pointer and cause a crash?
It should not happen see above.
> Additionally, since this does not hold the rtnl_lock(), could this race
> with concurrent administrative state changes (like 'ip link set dev down')
> and lead to a double-execution of tbnet_stop()?
As far as I can tell no because when these hooks are called userspace is
not running anymore (we are rebooting or shutting down).
^ permalink raw reply
* Re: [PATCH net-next] selftests: drv-net: rss: add case for field config on RSS context
From: Pavan Chebbi @ 2026-04-29 5:04 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, shuah,
dimitri.daskalakis1, linux-kselftest
In-Reply-To: <20260428203624.1224387-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 628 bytes --]
On Wed, Apr 29, 2026 at 2:06 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> We had some issues with a suspected traffic imbalance on an RSS
> context. Make sure the tests cover the RXFH field selection
> vs additional contexts.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> CC: shuah@kernel.org
> CC: dimitri.daskalakis1@gmail.com
> CC: pavan.chebbi@broadcom.com
> CC: linux-kselftest@vger.kernel.org
> ---
> .../selftests/drivers/net/hw/rss_ctx.py | 91 ++++++++++++++++++-
> 1 file changed, 90 insertions(+), 1 deletion(-)
>
LGTM.
Tested-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5469 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] net: thunderbolt: Fix lockdep issue during tunnel tear down
From: Mika Westerberg @ 2026-04-29 4:47 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, YehezkelShB, andrew+netdev, davem, edumazet, pabeni
In-Reply-To: <20260429011226.1505821-1-kuba@kernel.org>
On Tue, Apr 28, 2026 at 06:12:26PM -0700, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net: thunderbolt: Fix lockdep issue during tunnel tear down
>
> This commit attempts to fix a circular locking dependency warning in
> tbnet_tear_down() by dropping the connection lock earlier and returning if the
> connection isn't fully established.
>
> > diff --git a/drivers/net/thunderbolt/main.c b/drivers/net/thunderbolt/main.c
> > index 631af237998d..d8fcf18fc55c 100644
> > --- a/drivers/net/thunderbolt/main.c
> > +++ b/drivers/net/thunderbolt/main.c
> [ ... ]
> > @@ -372,48 +372,47 @@ static void tbnet_free_buffers(struct tbnet_ring *ring)
> >
> > static void tbnet_tear_down(struct tbnet *net, bool send_logout)
> > {
> > + int ret, retries = TBNET_LOGOUT_RETRIES;
> > +
> > netif_carrier_off(net->dev);
> > netif_stop_queue(net->dev);
> >
> > stop_login(net);
> >
> > mutex_lock(&net->connection_lock);
> > + if (!net->login_sent || !net->login_received) {
> > + mutex_unlock(&net->connection_lock);
> > + return;
> > + }
>
> If the connection is in a partially established state (e.g. login_sent is
> true, but login_received is false), this early return skips clearing the
> connection states.
>
> Could this stall the connection if a new TBIP_LOGIN arrives later?
> tbnet_handle_packet() would see net->login_sent as true and might fail to
> queue the login_work to reply.
I don't think that matters because tbnet_tear_down() is actually tearing
down the connection so after this we do not expect the connection to be
established until start_login() is called again (this happens when the
interface is brought up again or on resume).
> > + net->login_sent = false;
> > + net->login_received = false;
> > + mutex_unlock(&net->connection_lock);
>
> By releasing net->connection_lock here, the rest of the teardown process runs
> without mutual exclusion. Since the network interface is still running, is it
> possible for tbnet_handle_packet() to receive a new TBIP_LOGIN request right
> after this lock is dropped?
>
> If tbnet_handle_packet() acquires the lock, updates net->remote_transmit_path
> and brings up a new connection concurrently:
>
> CPU1
> tbnet_tear_down()
> mutex_unlock(&net->connection_lock);
>
> CPU2
> tbnet_handle_packet()
> mutex_lock(&net->connection_lock);
> net->remote_transmit_path = pkg->transmit_path;
> mutex_unlock(&net->connection_lock);
>
> CPU1
> tb_xdomain_release_in_hopid(net->xd, net->remote_transmit_path);
>
> Would CPU1 then erroneously release the newly established connection's hopid
> and free active buffers?
Oh, this one definitely can happen.
> >
> > - if (net->login_sent && net->login_received) {
> > - int ret, retries = TBNET_LOGOUT_RETRIES;
> [ ... ]
> > - tb_xdomain_release_in_hopid(net->xd, net->remote_transmit_path);
> > - net->remote_transmit_path = 0;
> > - }
> > + tb_xdomain_release_in_hopid(net->xd, net->remote_transmit_path);
> > + net->remote_transmit_path = 0;
> >
> > - net->login_retries = 0;
>
> With the unconditional clearing of net->login_retries removed, does the
> login_retries counter keep accumulating if tbnet_tear_down() returns early
> above?
>
> If it exceeds TBNET_LOGIN_RETRIES, could it permanently prevent new
> connections until the module is reloaded?
Indeed, that's an accidental removal.
Okay let me try to figure out better fix for this lockdep issue.
^ permalink raw reply
* Re: [PATCH net-next 4/4] r8152: Add firmware upload capability for RTL8157/RTL8159
From: Birger Koblitz @ 2026-04-29 4:21 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <d9d69a5a-be6e-4566-9ec3-e742f745a530@lunn.ch>
On 29/04/2026 3:57 am, Andrew Lunn wrote:
> On Tue, Apr 28, 2026 at 05:47:24AM +0200, Birger Koblitz wrote:
>> The RTL8159 requires firmware for its PHY in order to work at
>> connection speeds > 5GBit. Add support for uploading firmware for
>> the PHYs using the existing rtl8152_apply_firmware() function
>> in r8157_hw_phy_cfg() and set up the correct names for the firmware
>> files.
>>
>> If no firmware is found, both the RTL8157 and the RTL8159 will continue
>> to work.
>>
>> Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
>> ---
>> drivers/net/usb/r8152.c | 15 ++++++++++++++-
>> 1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
>> index 08cc3c1dae0facb2400890ba4d093c97ed56d40b..56e00fe6f32405ce753df3e03e54a7daaf1a29ac 100644
>> --- a/drivers/net/usb/r8152.c
>> +++ b/drivers/net/usb/r8152.c
>> @@ -4663,10 +4663,11 @@ static bool rtl8152_is_fw_phy_speed_up_ok(struct r8152 *tp, struct fw_phy_speed_
>> case RTL_VER_11:
>> case RTL_VER_12:
>> case RTL_VER_14:
>> - case RTL_VER_16:
>> goto out;
>> case RTL_VER_13:
>> case RTL_VER_15:
>> + case RTL_VER_16:
>> + case RTL_VER_17:
>
> Is that a bug fix?
>
> Andrew
No, since the RTL8157 (RTL_VER_16) also works in my experiments as
expected without this change, i.e. without any updated firmware, or
better the possibility to update the firmware. It is only for the
RTL8159 where the firmware is necessary to even get 10GBit performance,
at least for the link-partners I use for testing. My understanding of
the Realtek "firmware" is that it mainly provides updated calibration
constants, possibly better calibration routines for interoperability.
Unlike for many other drivers, the firmware is not necessary to make the
driver work at all.
Birger
^ permalink raw reply
* Re: [PATCH net-next 3/4] r8152: Add irq mitigation for RTL8157/9
From: Birger Koblitz @ 2026-04-29 4:06 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <06a42ba1-b714-45b1-be30-4a793752e495@lunn.ch>
On 29/04/2026 3:56 am, Andrew Lunn wrote:
> On Tue, Apr 28, 2026 at 05:47:23AM +0200, Birger Koblitz wrote:
>> Add interrupt mitigation code for both RTL8157 and RTL8159 that prevents
>> USB interrupt callbacks with urb->status ESHUTDOWN being triggered. While the
>> issue is rarely seen on the RTL8157, without the mitigation, it is
>> common on the RTL8159:
>> [273.561863] r8152 7-1:1.0 enx88c9b3b5xxxx: Stop submitting intr, status -108
>>
>> Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
>> ---
>> drivers/net/usb/r8152.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
>> index 8255261d73148a7b4dabe0188faf07cb1f356437..08cc3c1dae0facb2400890ba4d093c97ed56d40b 100644
>> --- a/drivers/net/usb/r8152.c
>> +++ b/drivers/net/usb/r8152.c
>> @@ -8444,6 +8444,12 @@ static void r8156_init(struct r8152 *tp)
>> else
>> r8153_u2p3en(tp, false);
>>
>> + if (tp->version >= RTL_VER_16) {
>> + /* Disable Interrupt Mitigation */
>> + ocp_byte_clr_bits(tp, MCU_TYPE_USB, 0xcf04,
>> + BIT(0) | BIT(1) | BIT(2) | BIT(7));
>> + }
>
> What does interrupt mitigation do?
>
> Is this a different name for interrupt coalescence, where the MAC
> delays interrupts for a period of time so more packets are in the
> receive ring when it does interrupt, so reducing the number of
> interrupts, and bigger bursts of packets are processed at once?
>
I do not understand what the mechanism behind this is, there is no more
documentation in the original driver. I experimented with this for some
time and the effect that I see is that it prevents interrupts after
shutdown. That is, why it is already done in rtl8153_unload(), again
like in the original driver, where it was more critical to prevent the
warnings.
I was hoping that Realtek could enlighten us.
Birger
^ permalink raw reply
* Re: [PATCH net v4 2/8] xsk: handle NULL dereference of the skb without frags issue
From: Jason Xing @ 2026-04-29 3:53 UTC (permalink / raw)
To: Simon Horman
Cc: davem, edumazet, kuba, pabeni, bjorn, magnus.karlsson,
maciej.fijalkowski, jonathan.lemon, sdf, ast, daniel, hawk,
john.fastabend, aleksander.lobakin, bpf, netdev, kernelxing
In-Reply-To: <20260428113333.1296663-3-horms@kernel.org>
On Tue, Apr 28, 2026 at 2:35 PM Simon Horman <horms@kernel.org> wrote:
>
> From: 'Simon Horman' <horms@kernel.org>
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://netdev-ai.bots.linux.dev/sashiko/
>
> Simon says:
>
> Hi Jason,
>
> I'm providing this for informational purposes.
> My unedrstanding is that the problem flagged below
> is not present with the full 8 patches of the series
> applied.
Hi simon,
Thanks for letting me know:)
Yes, it will disappear after applying the whole series.
>
> ---
> xsk: handle NULL dereference of the skb without frags issue
>
> This change guards the existing xsk_inc_num_desc()/xsk_drop_skb() calls
> in xsk_build_skb()'s free_err path with an xs->skb check, and adds a new
> else branch that cancels the reserved CQ slot and bumps invalid_descs
> when xs->skb is NULL.
>
> > diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> > index 887abed25466..54d4895fc11e 100644
> > --- a/net/xdp/xsk.c
> > +++ b/net/xdp/xsk.c
> > @@ -973,9 +973,14 @@ static struct sk_buff *xsk_build_skb(struct xdp_sock *xs,
> > kfree_skb(skb);
> >
> > if (err == -EOVERFLOW) {
> > - /* Drop the packet */
> > - xsk_inc_num_desc(xs->skb);
> > - xsk_drop_skb(xs->skb);
> > + if (xs->skb) {
> > + /* Drop the packet */
> > + xsk_inc_num_desc(xs->skb);
> > + xsk_drop_skb(xs->skb);
> > + } else {
> > + xsk_cq_cancel_locked(xs->pool, 1);
> > + xs->tx->invalid_descs++;
> > + }
>
> The changelog states:
>
> In this series, the skb is already freed by kfree_skb() inside
> xsk_build_skb_zerocopy for the first-descriptor case, so we only need
> to do the bookkeeping: cancel the one reserved CQ slot and account
> for the single invalid descriptor.
>
> Is that accurate for this commit?
The commit says "in this series,..." which might confuse the AI reviewer.
>
> Looking at xsk_build_skb_zerocopy() as it stands here, neither of its
> error returns actually frees the skb:
>
> if (!skb) {
> ...
> skb = sock_alloc_send_skb(&xs->sk, hr, 1, &err);
> if (unlikely(!skb))
> return ERR_PTR(err);
>
> skb_reserve(skb, hr);
>
> xsk_skb_init_misc(skb, xs, desc->addr);
> if (desc->options & XDP_TX_METADATA) {
> err = xsk_skb_metadata(skb, buffer, desc, pool, hr);
> if (unlikely(err))
> return ERR_PTR(err);
> }
> }
> ...
> for (copied = 0, i = skb_shinfo(skb)->nr_frags; copied < len; i++) {
> if (unlikely(i >= MAX_SKB_FRAGS))
> return ERR_PTR(-EOVERFLOW);
>
> page = pool->umem->pgs[addr >> PAGE_SHIFT];
> get_page(page);
> ...
> skb_fill_page_desc(skb, i, page, offset, copy);
> ...
> }
>
> So on the first-descriptor -EOVERFLOW path (xs->skb == NULL,
> IFF_TX_SKB_NO_LINEAR device), doesn't xsk_build_skb_zerocopy() return
> with the skb still allocated, up to MAX_SKB_FRAGS pages pinned via
> get_page() and attached through skb_fill_page_desc(), and an
> sk_wmem_alloc charge held by xsk_destruct_skb (installed by
> xsk_skb_init_misc)?
>
> Control then returns to xsk_build_skb():
>
> skb = xsk_build_skb_zerocopy(xs, desc);
> if (IS_ERR(skb)) {
> err = PTR_ERR(skb);
> skb = NULL;
> goto free_err;
> }
> ...
> free_err:
> if (skb && !skb_shinfo(skb)->nr_frags)
> kfree_skb(skb);
>
> Since the local skb has been set to NULL, the kfree_skb() guard is
> skipped, and the new else-branch only performs the CQ cancel and
> invalid_descs bump.
>
> Doesn't that leak the sk_buff, the attached frag pages, and the
> sk_wmem_alloc charge every time a first descriptor hits the i >=
> MAX_SKB_FRAGS condition (or the xsk_skb_metadata failure)?
This is the issue that I fixed in the subsequent patches.
>
> A later patch in the series, "xsk: free the skb when hitting the upper
> bound MAX_SKB_FRAGS", adds an "if (!xs->skb) kfree_skb(skb);" inside
> xsk_build_skb_zerocopy() before the -EOVERFLOW return, which seems to
> confirm the skb is not freed at this commit. Should the changelog's
> premise be reworked, or the free added here so each patch in the series
> stands on its own?
It's only about the description of the patch and the whole series
IIUC. If a new version is needed, I will send a v5 then :)
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH net-next 2/4] r8152: Add support for the RTL8159 chip
From: Birger Koblitz @ 2026-04-29 3:52 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <3e04d913-693c-44a9-a685-df9d0c9bd95f@lunn.ch>
Hi Andrew,
thanks for reviewing!
On 29/04/2026 3:52 am, Andrew Lunn wrote:
>> + case RTL_VER_17:
>> case RTL_VER_16:
>> ocp_byte_clr_bits(tp, MCU_TYPE_PLA, PLA_CR, CR_RE | CR_TE);
>
> nitpick. The other switch statements seem to be sorted. So 17 should
> be after 16.
Will fix in the next version.
>> + sram_write_w0w1(tp, 0x81b9, 0xff00, 0xb900);
>> + //nomal link TX filter
>
> normal? Please also add a space after the //. netdev also prefers /*
> */.
Will fix.
>> + sram2_write_w0w1(tp, 0x84b2, 0xff00, 0x6000);
>> + //Training AAGC PAR (with uc2 patch)
>
> space
Will fix.
>> + if (tp->version == RTL_VER_17 && r8159_wait_backup_restore(tp))
>> + return;
>
> You should probably do something with the return value from
> r8159_wait_backup_restore(). At minimum a dev_err().
>
I will add a dev_err() message.
Birger
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH v2] ice: wait for reset completion in ice_resume()
From: Aaron Ma @ 2026-04-29 3:49 UTC (permalink / raw)
To: Przemek Kitszel
Cc: Paul Menzel, Tony Nguyen, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, linux-kernel,
Akeem G Abodunrin, Jesse Brandeburg, intel-wired-lan, Kohei Enju
In-Reply-To: <9fd9877a-99d5-4710-a063-ca9a62d425c5@intel.com>
On Tue, Apr 28, 2026 at 9:08 PM Przemek Kitszel
<przemyslaw.kitszel@intel.com> wrote:
>
>
> >>>> + ret = ice_wait_for_reset(pf, 10 * HZ);
> >>>
> >>> Why not pass a delay in micro/milliseconds?
> >>
> >> ice_wait_for_reset() takes jiffies — that's the existing API.
> >
> > It’s recommended to use `msecs_to_jiffies()` to make it HZ invariant.
>
> there is also secs_to_jiffies()
Thank you very much.
V4 is sent.
Aaron
>
> >
> >>>> + if (ret)
> >>>> + dev_err(dev, "Wait for reset failed during resume:
> >>>> %d\n", ret);
> >>>
> >>> Mention the delay?
> >>
> >> Good point. I'll include the timeout in the error message in v3.
> >
> > Awesome.
> >
> > […]
> >
> >
> > Thanks,
> >
> > Paul
>
^ permalink raw reply
* [PATCH v4] ice: wait for reset completion in ice_resume()
From: Aaron Ma @ 2026-04-29 3:48 UTC (permalink / raw)
To: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
Cc: Akeem G Abodunrin, Jesse Brandeburg, intel-wired-lan,
aleksandr.loktionov, kohei, Paul Menzel
ice_resume() schedules an asynchronous PF reset and returns
immediately. The reset runs later in ice_service_task(). If
userspace tries to bring up the net device before the reset
finishes, ice_open() fails with -EBUSY:
ice_resume()
ice_schedule_reset() # sets ICE_PFR_REQ, returns
...
ice_open()
ice_is_reset_in_progress() # ICE_PFR_REQ still set, -EBUSY
...
ice_service_task()
ice_do_reset()
ice_rebuild() # clears ICE_PFR_REQ, too late
Reproduced on E800 series NICs during suspend/resume with irdma
enabled, where the aux device probe widens the race window.
ice 0000:81:00.0: can't open net device while reset is in progress
Add a best-effort wait (10s timeout, matching ice_devlink_info_get())
for the reset to complete before returning from ice_resume(). In
practice the reset completes in ~300ms.
Fixes: 769c500dcc1e ("ice: Add advanced power mgmt for WoL")
Cc: stable@vger.kernel.org
Reviewed-by: Kohei Enju <kohei@enjuk.jp>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
---
v4: use secs_to_jiffies() instead of 10 * HZ (Przemek Kitszel)
v3: add error message to commit message for searchability, mention
timeout in dev_err (Paul Menzel)
v2: reword comment to clarify best-effort semantics (Kohei Enju)
v1: https://lore.kernel.org/intel-wired-lan/20260402024220.210466-1-aaron.ma@canonical.com/
drivers/net/ethernet/intel/ice/ice_main.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 5f92377d4dfc2..5fce644dc658e 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -5635,6 +5635,16 @@ static int ice_resume(struct device *dev)
/* Restart the service task */
mod_timer(&pf->serv_tmr, round_jiffies(jiffies + pf->serv_tmr_period));
+ /* Best-effort wait for the scheduled reset to finish so that the
+ * device is operational before returning. Without this, userspace
+ * (e.g. NetworkManager) may try to open the net device while the
+ * asynchronous reset is still in progress, hitting -EBUSY.
+ */
+ ret = ice_wait_for_reset(pf, secs_to_jiffies(10));
+ if (ret)
+ dev_err(dev, "Wait for reset timed out (10s) during resume: %d\n",
+ ret);
+
return 0;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net v4 8/8] xsk: fix u64 descriptor address truncation on 32-bit architectures
From: Jason Xing @ 2026-04-29 3:41 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: davem, edumazet, kuba, pabeni, bjorn, magnus.karlsson,
maciej.fijalkowski, jonathan.lemon, sdf, ast, daniel, hawk,
john.fastabend, aleksander.lobakin, bpf, netdev, Jason Xing
In-Reply-To: <afE7EFYdrNg1u_g2@devvm7509.cco0.facebook.com>
On Wed, Apr 29, 2026 at 2:11 AM Stanislav Fomichev <sdf.kernel@gmail.com> wrote:
>
> On 04/24, Jason Xing wrote:
> > From: Jason Xing <kernelxing@tencent.com>
> >
> > In copy mode TX, xsk_skb_destructor_set_addr() stores the 64-bit
> > descriptor address into skb_shinfo(skb)->destructor_arg (void *) via a
> > uintptr_t cast:
> >
> > skb_shinfo(skb)->destructor_arg = (void *)((uintptr_t)addr | 0x1UL);
> >
> > On 32-bit architectures uintptr_t is 32 bits, so the upper 32 bits of
> > the descriptor address are silently dropped. In unaligned mode the chunk
> > offset is encoded in bits 48-63 of the descriptor address
> > (XSK_UNALIGNED_BUF_OFFSET_SHIFT = 48), meaning the offset is lost
> > entirely. The completion queue then returns a truncated address to
> > userspace, making buffer recycling impossible.
> >
> > Fix this by handling the 32-bit case in the destructor_arg helpers:
> >
> > - xsk_skb_destructor_set_addr(): on !CONFIG_64BIT, allocate an
> > xsk_addrs struct via kmem_cache_zalloc() to store the full u64
> > address. Leave num_descs as 0 (zalloc) so that the subsequent
> > xsk_inc_num_desc() brings it to the correct count of 1.
> >
> > - xsk_skb_destructor_is_addr(): on !CONFIG_64BIT, return true only
> > when destructor_arg is NULL (not yet set), false when it points to
> > an xsk_addrs struct.
> >
> > - xsk_skb_init_misc(): call xsk_skb_destructor_set_addr() first
> > before touching any other skb fields; on failure return early so
> > the skb destructor is never changed from sock_wfree.
> >
> > The existing xsk_consume_skb() already handles 32-bit correctly after
> > these changes: xsk_skb_destructor_is_addr() returns false for any
> > allocated xsk_addrs, so the kmem_cache_free path is always taken.
> >
> > The overhead is one extra kmem_cache_zalloc per first descriptor on
> > 32-bit only; 64-bit builds are completely unchanged.
> >
> > Closes: https://lore.kernel.org/all/20260419045824.D9E5EC2BCAF@smtp.kernel.org/
> > Fixes: 0ebc27a4c67d ("xsk: avoid data corruption on cq descriptor number")
> > Signed-off-by: Jason Xing <kernelxing@tencent.com>
> > ---
> > net/xdp/xsk.c | 38 +++++++++++++++++++++++++++++++-------
> > 1 file changed, 31 insertions(+), 7 deletions(-)
> >
> > diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> > index ed96f6ec8ff2..fe88f47741b5 100644
> > --- a/net/xdp/xsk.c
> > +++ b/net/xdp/xsk.c
> > @@ -558,7 +558,10 @@ static int xsk_cq_reserve_locked(struct xsk_buff_pool *pool)
> >
> > static bool xsk_skb_destructor_is_addr(struct sk_buff *skb)
> > {
> > - return (uintptr_t)skb_shinfo(skb)->destructor_arg & 0x1UL;
> > + if (IS_ENABLED(CONFIG_64BIT))
> > + return (uintptr_t)skb_shinfo(skb)->destructor_arg & 0x1UL;
> > + else
> > + return !skb_shinfo(skb)->destructor_arg;
>
> Don't understand why we need to special case CONFIG_64BIT here?
> Shouldn't the same existing condition work on 32bit?
Because 0x1UL is the particular semantic applied on a 64-bit arch.
xsk_skb_destructor_set_addr() sets it while
xsk_skb_destructor_is_addr() recognizes it. They are a pair.
As you noticed, one liner works but is not that appropriate: on a
32-bit arch, this member should be either a NULL point or a valid
pointer pointing to a memory region. Testing if it's NULL can be
helpful as to the long term maintenance because of its readability and
robustness/safety.
The error path in allocation of skb is really complex, which is why
I'm so cautious to take care of it :)
I've noticed the status has been changed to 'changes requested'. Does
that mean one way or another I have to post a new version?
Thanks,
Jason
>
> > }
> >
> > static u64 xsk_skb_destructor_get_addr(struct sk_buff *skb)
> > @@ -566,9 +569,21 @@ static u64 xsk_skb_destructor_get_addr(struct sk_buff *skb)
> > return (u64)((uintptr_t)skb_shinfo(skb)->destructor_arg & ~0x1UL);
> > }
> >
> > -static void xsk_skb_destructor_set_addr(struct sk_buff *skb, u64 addr)
> > +static int xsk_skb_destructor_set_addr(struct sk_buff *skb, u64 addr)
> > {
>
> [..]
>
> > + if (!IS_ENABLED(CONFIG_64BIT)) {
> > + struct xsk_addrs *xsk_addr;
> > +
> > + xsk_addr = kmem_cache_zalloc(xsk_tx_generic_cache, GFP_KERNEL);
> > + if (!xsk_addr)
> > + return -ENOMEM;
> > + xsk_addr->addrs[0] = addr;
> > + skb_shinfo(skb)->destructor_arg = (void *)xsk_addr;
> > + return 0;
> > + }
> > +
> > skb_shinfo(skb)->destructor_arg = (void *)((uintptr_t)addr | 0x1UL);
> > + return 0;
>
> I think this is gonna be a 3rd copy paste of the same logic? Let's
> move to a new helper and replace existing kmem_cache_zalloc places?
>
> xsk_skb_destructor_alloc_list(prev_addr) ?
^ permalink raw reply
* Re: [PATCHv2 net-next] net: bcmasp: handle EPROBE_DEFER for MAC retrieval
From: Rosen Penev @ 2026-04-29 3:36 UTC (permalink / raw)
To: Justin Chen
Cc: netdev, Florian Fainelli, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni,
open list:BROADCOM ASP 2.0 ETHERNET DRIVER, open list
In-Reply-To: <df793a62-b0a6-4500-94e1-05ad54ba830f@broadcom.com>
On Tue, Apr 28, 2026 at 10:43 AM Justin Chen <justin.chen@broadcom.com> wrote:
>
>
>
> On 4/27/26 6:43 PM, Rosen Penev wrote:
> > of_get_ethdev_address can return EPROBE_DEFER when using nvmem. To
> > handle this, encode the error with ERR_PTR for minimal changes. Adjust
> > the only place using bcmasp_interface_create.
> >
> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > ---
> > v2: use dev_err_probe.
> > drivers/net/ethernet/broadcom/asp2/bcmasp.c | 6 +++---
> > drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c | 6 ++++--
> > 2 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp.c b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
> > index 972474893a6b..e9b11b956344 100644
> > --- a/drivers/net/ethernet/broadcom/asp2/bcmasp.c
> > +++ b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
> > @@ -1333,10 +1333,10 @@ static int bcmasp_probe(struct platform_device *pdev)
> > i = 0;
> > for_each_available_child_of_node_scoped(ports_node, intf_node) {
> > intf = bcmasp_interface_create(priv, intf_node, i);
> > - if (!intf) {
> > - dev_err(dev, "Cannot create eth interface %d\n", i);
> > + if (IS_ERR(intf)) {
> > of_node_put(ports_node);
> > - ret = -EINVAL;
> > + ret = dev_err_probe(dev, PTR_ERR(intf), "Cannot create eth interface %d\n",
> > + i);
> > goto err_cleanup;
> > }
> > list_add_tail(&intf->list, &priv->intfs);
> > diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
> > index ec63f50a849e..caf0e408e2f7 100644
> > --- a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
> > +++ b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
> > @@ -1254,7 +1254,7 @@ struct bcmasp_intf *bcmasp_interface_create(struct bcmasp_priv *priv,
> > struct device *dev = &priv->pdev->dev;
> > struct bcmasp_intf *intf;
> > struct net_device *ndev;
> > - int ch, port, ret;
> > + int ch, port, ret = -EINVAL;
> >
> > if (of_property_read_u32(ndev_dn, "reg", &port)) {
> > dev_warn(dev, "%s: invalid port number\n", ndev_dn->name);
> > @@ -1314,6 +1314,8 @@ struct bcmasp_intf *bcmasp_interface_create(struct bcmasp_priv *priv,
> > }
> >
> > ret = of_get_ethdev_address(ndev_dn, ndev);
> > + if (ret == -EPROBE_DEFER)
> > + return ERR_PTR(-EPROBE_DEFER);
>
> Do we need to hit unwind here? i.e. goto err_deregister_fixed_link.
Yes we do. In other news I just sent another v2 by accident. Guess
I'll wait to send a v4...
>
> Thanks,
> Justin
>
> > if (ret) {
> > netdev_warn(ndev, "using random Ethernet MAC\n");
> > eth_hw_addr_random(ndev);
> > @@ -1340,7 +1342,7 @@ struct bcmasp_intf *bcmasp_interface_create(struct bcmasp_priv *priv,
> > err_free_netdev:
> > free_netdev(ndev);
> > err:
> > - return NULL;
> > + return ERR_PTR(ret);
> > }
> >
> > void bcmasp_interface_destroy(struct bcmasp_intf *intf)
>
^ permalink raw reply
* [PATCHv2 net-next] net: bcmasp: handle EPROBE_DEFER for MAC retrieval
From: Rosen Penev @ 2026-04-29 3:34 UTC (permalink / raw)
To: netdev
Cc: Justin Chen, Florian Fainelli, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni,
open list:BROADCOM ASP 2.0 ETHERNET DRIVER, open list
of_get_ethdev_address can return EPROBE_DEFER when using nvmem. To
handle this, encode the error with ERR_PTR for minimal changes. Adjust
the only place using bcmasp_interface_create.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
v2: use goto after of_get_mac_address probe deferral
drivers/net/ethernet/broadcom/asp2/bcmasp.c | 6 +++---
drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c | 6 ++++--
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp.c b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
index 972474893a6b..e9b11b956344 100644
--- a/drivers/net/ethernet/broadcom/asp2/bcmasp.c
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
@@ -1333,10 +1333,10 @@ static int bcmasp_probe(struct platform_device *pdev)
i = 0;
for_each_available_child_of_node_scoped(ports_node, intf_node) {
intf = bcmasp_interface_create(priv, intf_node, i);
- if (!intf) {
- dev_err(dev, "Cannot create eth interface %d\n", i);
+ if (IS_ERR(intf)) {
of_node_put(ports_node);
- ret = -EINVAL;
+ ret = dev_err_probe(dev, PTR_ERR(intf), "Cannot create eth interface %d\n",
+ i);
goto err_cleanup;
}
list_add_tail(&intf->list, &priv->intfs);
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
index ec63f50a849e..4c34bf16bb76 100644
--- a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
@@ -1254,7 +1254,7 @@ struct bcmasp_intf *bcmasp_interface_create(struct bcmasp_priv *priv,
struct device *dev = &priv->pdev->dev;
struct bcmasp_intf *intf;
struct net_device *ndev;
- int ch, port, ret;
+ int ch, port, ret = -EINVAL;
if (of_property_read_u32(ndev_dn, "reg", &port)) {
dev_warn(dev, "%s: invalid port number\n", ndev_dn->name);
@@ -1314,6 +1314,8 @@ struct bcmasp_intf *bcmasp_interface_create(struct bcmasp_priv *priv,
}
ret = of_get_ethdev_address(ndev_dn, ndev);
+ if (ret == -EPROBE_DEFER)
+ goto err_deregister_fixed_link;
if (ret) {
netdev_warn(ndev, "using random Ethernet MAC\n");
eth_hw_addr_random(ndev);
@@ -1340,7 +1342,7 @@ struct bcmasp_intf *bcmasp_interface_create(struct bcmasp_priv *priv,
err_free_netdev:
free_netdev(ndev);
err:
- return NULL;
+ return ERR_PTR(ret);
}
void bcmasp_interface_destroy(struct bcmasp_intf *intf)
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net-next] net: gianfar: use alloc_ethdev_mqs
From: Rosen Penev @ 2026-04-29 3:17 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Claudiu Manoil, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, open list
In-Reply-To: <d807e204-0052-4a33-b711-e372c7695023@lunn.ch>
On Tue, Apr 28, 2026 at 5:41 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > > + *pdev = alloc_etherdev_mqs(sizeof(*priv), num_tx_qs, num_rx_qs);
> > > > dev = *pdev;
> > > > if (NULL == dev)
> > > > return -ENOMEM;
> > > > @@ -679,10 +679,6 @@ static int gfar_of_init(struct platform_device *ofdev, struct net_device **pdev)
> > > >
> > > > priv->mode = mode;
> > > >
> > > > - priv->num_tx_queues = num_tx_qs;
> > > > - netif_set_real_num_rx_queues(dev, num_rx_qs);
> > > > - priv->num_rx_queues = num_rx_qs;
> > >
> > > Please add to the commit message an explanation of why these two
> > > assignments can be removed, because it is not obvious.
> > I didn't explain that _mqs sets them?
>
> How can alloc_etherdev_mqs() set them? priv is opaque to the core. All
> the core knows is the size of struct gfar_private, but nothing about
> its layout, where num_tx_queues and num_rx_queues are within priv.
I see what you mean. Will respin this.
>
> Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/3] psp: add a comment about a psp_dev add netlink notification
From: Willem de Bruijn @ 2026-04-29 2:48 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms,
willemdebruijn.kernel, daniel.zahka, Jakub Kicinski
In-Reply-To: <20260428205352.1247325-3-kuba@kernel.org>
Jakub Kicinski wrote:
> In psp_dev_create(), the DEV_ADD_NTF netlink notification is sent
> before the device is published to the netdev via rcu_assign_pointer().
> IIRC this is intentional because a single PSP device is expected
> to be shared with multiple netdevs. So we are trying to default to
> not having the netdev info. We can change it if someone complains
> but for now just add a comment that it's intentional.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH net-next 1/3] psp: validate protocol before mutating skb in psp_dev_encapsulate()
From: Willem de Bruijn @ 2026-04-29 2:47 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms,
willemdebruijn.kernel, daniel.zahka, Jakub Kicinski
In-Reply-To: <20260428205352.1247325-2-kuba@kernel.org>
Jakub Kicinski wrote:
> Code checkers / AI scans will complain that we have already modified
> the packet by the time we realize that protocol is not IP.
>
> Move the skb->protocol check to before skb_push()/memmove() so that
> the skb is not left in a corrupted state when the function returns
> false for an unsupported protocol. psp_dev_rcv() follows similar
> pattern.
>
> Today this path is unreachable because both in-tree callers (mlx5 and
> netdevsim) only reach psp_dev_encapsulate() from TCP socket TX paths
> where skb->protocol is always ETH_P_IP or ETH_P_IPV6, and both drop
> the skb on a false return, anyway.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
> ---
> net/psp/psp_main.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/net/psp/psp_main.c b/net/psp/psp_main.c
> index 9508b6c38003..652ec8a9c8a4 100644
> --- a/net/psp/psp_main.c
> +++ b/net/psp/psp_main.c
> @@ -228,6 +228,10 @@ bool psp_dev_encapsulate(struct net *net, struct sk_buff *skb, __be32 spi,
> u32 ethr_len = skb_mac_header_len(skb);
> u32 bufflen = ethr_len + network_len;
>
> + if (skb->protocol != htons(ETH_P_IP) &&
> + skb->protocol != htons(ETH_P_IPV6))
> + return false;
> +
> if (skb_cow_head(skb, PSP_ENCAP_HLEN))
> return false;
>
> @@ -243,11 +247,9 @@ bool psp_dev_encapsulate(struct net *net, struct sk_buff *skb, __be32 spi,
> ip_hdr(skb)->check = 0;
> ip_hdr(skb)->check =
> ip_fast_csum((u8 *)ip_hdr(skb), ip_hdr(skb)->ihl);
> - } else if (skb->protocol == htons(ETH_P_IPV6)) {
> + } else {
> ipv6_hdr(skb)->nexthdr = IPPROTO_UDP;
> be16_add_cpu(&ipv6_hdr(skb)->payload_len, PSP_ENCAP_HLEN);
> - } else {
> - return false;
> }
>
> skb_set_inner_ipproto(skb, IPPROTO_TCP);
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH net-next 3/3] psp: validate IPv4 header fields in psp_dev_rcv()
From: Willem de Bruijn @ 2026-04-29 2:42 UTC (permalink / raw)
To: Jakub Kicinski, Willem de Bruijn
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms,
daniel.zahka
In-Reply-To: <20260428184336.2244b6a1@kernel.org>
Jakub Kicinski wrote:
> On Tue, 28 Apr 2026 20:22:34 -0400 Willem de Bruijn wrote:
> > Jakub Kicinski wrote:
> > > psp_dev_rcv() is called from the NIC driver's RX completion path
> > > before the frame reaches ip_rcv_core(), so the IP header has not
> > > been validated in SW, yet. We expect that the device has done
> > > all this validation, but let's also add the SW checks, to avoid
> > > surprises.
> >
> > If devices are expected to have verified this, should these be more
> > noisy checks, similar to netdev_rx_csum_fault?
>
> Maybe "expect" is a bit of a strong word, I meant "anticipate" /
> "suspect". Dropping invalid packet in SW doesn't seem like a huge
> problem, other paths in this function already do. For rx csum the
> problem is that we got a incorrectly math'ed out value for what is
> likely a valid packet.
>
> That's just to explain my thinking, if you prefer we warn / dump skb
> I can respin.
No, sounds good.
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox