* Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration
From: Andrew Lunn @ 2026-04-06 15:21 UTC (permalink / raw)
To: Carlo Szelinsky
Cc: Oleksij Rempel, Kory Maincent, Andrew Lunn, Heiner Kallweit,
Russell King, Jakub Kicinski, David S . Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, netdev, linux-kernel
In-Reply-To: <20260406144324.4007913-1-github@szelinsky.de>
On Mon, Apr 06, 2026 at 04:43:24PM +0200, Carlo Szelinsky wrote:
> Hi Andrew, Oleksij,
>
> Thanks for pushing me in the right direction here.
>
> So if I understand correctly, I should move the PSE control lookup
> from fwnode_mdiobus_register_phy() into phy_probe(). That way the PHY
> just defers like any other device if the PSE controller isn't there
> yet, and the bus scan keeps going for the other PHYs.
Ah, yes. That is the correct fix.
Andrew
^ permalink raw reply
* Re: [PATCH v3 00/15] firmware: qcom: Add OP-TEE PAS service support
From: Bjorn Andersson @ 2026-04-06 15:09 UTC (permalink / raw)
To: Sumit Garg
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
jorge.ramirez, tonyh, vignesh.viswanathan, srinivas.kandagatla,
amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
harshal.dev, linux-kernel, Sumit Garg
In-Reply-To: <20260327131043.627120-1-sumit.garg@kernel.org>
On Fri, Mar 27, 2026 at 06:40:28PM +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Qcom platforms has the legacy of using non-standard SCM calls
> splintered over the various kernel drivers. These SCM calls aren't
> compliant with the standard SMC calling conventions which is a
> prerequisite to enable migration to the FF-A specifications from Arm.
>
Please get our colleagues involved in this discussion, because this
non-SCM interface does not match the direction we are taking.
Regards,
Bjorn
> OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't
> support these non-standard SCM calls. And even for newer architectures
> using S-EL2 with Hafnium support, QTEE won't be able to support SCM
> calls either with FF-A requirements coming in. And with both OP-TEE
> and QTEE drivers well integrated in the TEE subsystem, it makes further
> sense to reuse the TEE bus client drivers infrastructure.
>
> The added benefit of TEE bus infrastructure is that there is support
> for discoverable/enumerable services. With that client drivers don't
> have to manually invoke a special SCM call to know the service status.
>
> So enable the generic Peripheral Authentication Service (PAS) provided
> by the firmware. It acts as the common layer with different TZ
> backends plugged in whether it's an SCM implementation or a proper
> TEE bus based PAS service implementation.
>
> The TEE PAS service ABI is designed to be extensible with additional API
> as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future
> extensions of the PAS service needed while still maintaining backwards
> compatibility.
>
> Currently OP-TEE support is being added to provide the backend PAS
> service implementation which can be found as part of this PR [1].
> This implementation has been tested on Kodiak/RB3Gen2 board with lemans
> EVK board being the next target. In addition to that WIN/IPQ targets
> planning to use OP-TEE will use this service too. Surely the backwards
> compatibility is maintained and tested for SCM backend.
>
> Patch summary:
> - Patch #1: adds Kodiak EL2 overlay since boot stack with TF-A/OP-TEE
> only allow UEFI and Linux to boot in EL2.
> - Patch #2: adds generic PAS service.
> - Patch #3: migrates SCM backend to generic PAS service.
> - Patch #4: adds TEE/OP-TEE backend for generic PAS service.
> - Patch #5-#13: migrates all client drivers to generic PAS service.
> - Patch #14: drops legacy PAS SCM exported APIs.
>
> The patch-set is based on v7.0-rc5 tag and can be found in git tree here
> [2].
>
> Merge strategy:
>
> It is expected due to APIs dependency, the entire patch-set to go via
> the Qcom tree. All other subsystem maintainers, it will be great if I
> can get acks for the corresponding subsystem patches.
>
> [1] https://github.com/OP-TEE/optee_os/pull/7721
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h=qcom-pas-v3
>
> ---
> Changes in v3:
> - Incorporated some style and misc. comments for patch #2, #3 and #4.
> - Add QCOM_PAS Kconfig dependency for various subsystems.
> - Switch from pseudo TA to proper TA invoke commands.
>
> Changes in v2:
> - Fixed kernel doc warnings.
> - Polish commit message and comments for patch #2.
> - Pass proper PAS ID in set_remote_state API for media firmware drivers.
> - Added Maintainer entry and dropped MODULE_AUTHOR.
>
> Mukesh Ojha (1):
> arm64: dts: qcom: kodiak: Add EL2 overlay
>
> Sumit Garg (14):
> firmware: qcom: Add a generic PAS service
> firmware: qcom_scm: Migrate to generic PAS service
> firmware: qcom: Add a PAS TEE service
> remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs
> remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs
> soc: qcom: mdtloader: Switch to generic PAS TZ APIs
> remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs
> remoteproc: qcom: Select QCOM_PAS generic service
> drm/msm: Switch to generic PAS TZ APIs
> media: qcom: Switch to generic PAS TZ APIs
> net: ipa: Switch to generic PAS TZ APIs
> wifi: ath12k: Switch to generic PAS TZ APIs
> firmware: qcom_scm: Remove SCM PAS wrappers
> MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service
>
> MAINTAINERS | 9 +
> arch/arm64/boot/dts/qcom/Makefile | 2 +
> arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++
> drivers/firmware/qcom/Kconfig | 19 +
> drivers/firmware/qcom/Makefile | 2 +
> drivers/firmware/qcom/qcom_pas.c | 288 +++++++++++
> drivers/firmware/qcom/qcom_pas.h | 50 ++
> drivers/firmware/qcom/qcom_pas_tee.c | 478 ++++++++++++++++++
> drivers/firmware/qcom/qcom_scm.c | 302 ++++-------
> drivers/gpu/drm/msm/Kconfig | 1 +
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +-
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +-
> drivers/media/platform/qcom/iris/Kconfig | 25 +-
> .../media/platform/qcom/iris/iris_firmware.c | 9 +-
> drivers/media/platform/qcom/venus/Kconfig | 1 +
> drivers/media/platform/qcom/venus/firmware.c | 11 +-
> drivers/net/ipa/Kconfig | 2 +-
> drivers/net/ipa/ipa_main.c | 13 +-
> drivers/net/wireless/ath/ath12k/Kconfig | 2 +-
> drivers/net/wireless/ath/ath12k/ahb.c | 8 +-
> drivers/remoteproc/Kconfig | 1 +
> drivers/remoteproc/qcom_q6v5_mss.c | 5 +-
> drivers/remoteproc/qcom_q6v5_pas.c | 51 +-
> drivers/remoteproc/qcom_wcnss.c | 12 +-
> drivers/soc/qcom/mdt_loader.c | 12 +-
> include/linux/firmware/qcom/qcom_pas.h | 43 ++
> include/linux/firmware/qcom/qcom_scm.h | 29 --
> include/linux/soc/qcom/mdt_loader.h | 6 +-
> 28 files changed, 1114 insertions(+), 317 deletions(-)
> create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> create mode 100644 drivers/firmware/qcom/qcom_pas.c
> create mode 100644 drivers/firmware/qcom/qcom_pas.h
> create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c
> create mode 100644 include/linux/firmware/qcom/qcom_pas.h
>
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH net-next] net/mlx5: Update the list of the PCI supported devices
From: Simon Horman @ 2026-04-06 15:02 UTC (permalink / raw)
To: Tariq Toukan
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller, Saeed Mahameed, Leon Romanovsky, Mark Bloch,
netdev, linux-rdma, linux-kernel, Gal Pressman, Michael Guralnik,
stable, Patrisious Haddad
In-Reply-To: <20260403091756.139583-1-tariqt@nvidia.com>
On Fri, Apr 03, 2026 at 12:17:56PM +0300, Tariq Toukan wrote:
> From: Michael Guralnik <michaelgur@nvidia.com>
>
> Add the upcoming ConnectX-10 NVLink-C2C device ID to the table of
> supported PCI device IDs.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Michael Guralnik <michaelgur@nvidia.com>
> Reviewed-by: Patrisious Haddad <phaddad@nvidia.com>
> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* [PATCH net] ice: fix VF queue configuration with low MTU values
From: Jose Ignacio Tornos Martinez @ 2026-04-06 14:56 UTC (permalink / raw)
To: intel-wired-lan
Cc: netdev, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jacob Keller, Aleksandr Loktionov, Michal Swiatkowski,
Dave Ertman, Michal Kubiak, Jose Ignacio Tornos Martinez, stable
The ice driver's VF queue configuration validation rejects
databuffer_size values below 1024 bytes, which prevents VFs from
using MTU values below 871 bytes.
The iavf driver calculates databuffer_size based on the MTU using:
databuffer_size = ALIGN(MTU + LIBETH_RX_LL_LEN, 128)
where LIBETH_RX_LL_LEN = 26 (ETH_HLEN + 2*VLAN_HLEN + ETH_FCS_LEN).
For MTU values below 871:
MTU 870: 870 + 26 = 896, aligned to 128 = 896 (< 1024, rejected)
MTU 871: 871 + 26 = 897, aligned to 128 = 1024 (>= 1024, accepted)
The 1024-byte minimum seems unnecessarily restrictive, because the hardware
supports databuffer_size as low as 128 bytes (the alignment boundary),
which should allow MTU values down to the standard minimum of 68 bytes.
I haven't found the reason why the limit was configured in the commit
9c7dd7566d18 ("ice: add validation in OP_CONFIG_VSI_QUEUES VF message"), so
with no more information and since it is working, change the minimum
databuffer_size validation from 1024 to 128 bytes to allow standard low
MTU values while still preventing invalid configurations.
Fixes: 9c7dd7566d18 ("ice: add validation in OP_CONFIG_VSI_QUEUES VF message")
cc: stable@vger.kernel.org
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
drivers/net/ethernet/intel/ice/virt/queues.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/virt/queues.c b/drivers/net/ethernet/intel/ice/virt/queues.c
index f73d5a3e83d4..31be2f76181c 100644
--- a/drivers/net/ethernet/intel/ice/virt/queues.c
+++ b/drivers/net/ethernet/intel/ice/virt/queues.c
@@ -840,7 +840,7 @@ int ice_vc_cfg_qs_msg(struct ice_vf *vf, u8 *msg)
if (qpi->rxq.databuffer_size != 0 &&
(qpi->rxq.databuffer_size > ((16 * 1024) - 128) ||
- qpi->rxq.databuffer_size < 1024))
+ qpi->rxq.databuffer_size < 128))
goto error_param;
ring->rx_buf_len = qpi->rxq.databuffer_size;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next] selftests: drv-net: adjust to socat changes
From: Stanislav Fomichev @ 2026-04-06 14:55 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, leitao,
shuah, hawk, john.fastabend, sdf, linux-kselftest
In-Reply-To: <20260404230103.2719103-1-kuba@kernel.org>
On 04/04, Jakub Kicinski wrote:
> socat v1.8.1.0 now defaults to shut-null, it sends an extra
> 0-length UDP packet when sender disconnects. This breaks
> our tests which expect the exact packet sequence.
>
> Add shut-none which was the old default where necessary.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> CC: leitao@debian.org
> CC: shuah@kernel.org
> CC: hawk@kernel.org
> CC: john.fastabend@gmail.com
> CC: sdf@fomichev.me
> CC: linux-kselftest@vger.kernel.org
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
^ permalink raw reply
* Re: [RFC net-next 15/15] Documentation: networking: add ipxlat translator guide
From: Xavier Hsinyuan @ 2026-04-06 14:50 UTC (permalink / raw)
To: ralf
Cc: antonio, corbet, davem, dxld, edumazet, horms, kuba, linux-doc,
linux-kernel, netdev, pabeni, skhan
In-Reply-To: <20260319151230.655687-16-ralf@mandelbit.com>
Hi Ralf,
>+ $ ./tools/net/ynl/pyynl/cli.py --family ipxlat --json '{"ifindex": $IID, \
>+ "config": {"xlat-prefix6": "'$HEX_ADDR'", "prefix-len": 96} }'
Should this be like:
$ python3 /extends/pyynl/cli.py --spec ipxlat.yaml --do dev-set --json \
'{"ifindex": "'$IID'", "config": {"xlat-prefix6": \
{"prefix":"'$ADDR_HEX'", "prefix-len": 96}}}'
>+Address Translation
>+-------------------
>+
>+The ipxlat address translation algorithm is stateless, per RFC-ADDR_, all
>+possible IPv4 addressess are mapped one-to-one into the translation prefix,
>+optionally including a non-standard "suffix". See `RFC-ADDR Section 2.2
>+<https://datatracker.ietf.org/doc/html/rfc6052#section-2.2>`_.
>+
>+.. _RFC-ADDR: https://datatracker.ietf.org/doc/html/rfc6052
>+
>+IPv6 addressess outside this prefix are rejected with ICMPv6 errors with
>+the notable exception of ICMPv6 errors originating from untranslatable
>+source addressess. These are translated to be sourced from the IPv4 Dummy
>+Address ``192.0.0.8`` (per I-D-dummy_) instead to maintain IPv4 traceroute
>+visibility.
Would it help to add a few example? For instance,
- Interface ipxlat0 with prefix6=64:ff9b::/96.
- A IPv6 packet with src=64:ff9b::192.0.2.1 dst=64:ff9b::198.51.100.1,
was send to ipxlat0.
- Then a IPv4 packet with src=192.0.2.1 dst=198.51.100.1 was received from
ipxlat0.
Best regards,
Xavier
^ permalink raw reply
* Re: [PATCH net-next] pppoe: drop PFC frames
From: Simon Horman @ 2026-04-06 14:48 UTC (permalink / raw)
To: Qingfang Deng
Cc: linux-ppp, Michal Ostrowski, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, linux-kernel,
Paul Mackerras, Jaco Kroon, James Carlson, Wojciech Drewek,
Guillaume Nault
In-Reply-To: <20260403083926.68320-1-qingfang.deng@linux.dev>
On Fri, Apr 03, 2026 at 04:39:26PM +0800, Qingfang Deng wrote:
> RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT
> RECOMMENDED for PPPoE. In practice, pppd does not support negotiating
> PFC for PPPoE sessions, and the current PPPoE driver assumes an
> uncompressed (2-byte) protocol field.
>
> If a peer with a broken implementation or an attacker sends a frame with
> a compressed (1-byte) protocol field, the subsequent PPP payload is
> shifted by one byte. This causes the network header to be 4-byte
> misaligned, which may trigger unaligned access exceptions on some
> architectures.
>
> To reduce the attack surface, drop the compressed protocol field frames.
>
> Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
> ---
> drivers/net/ppp/pppoe.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
> index 1ac61c273b28..457a83c73293 100644
> --- a/drivers/net/ppp/pppoe.c
> +++ b/drivers/net/ppp/pppoe.c
> @@ -393,7 +393,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
> if (skb_mac_header_len(skb) < ETH_HLEN)
> goto drop;
>
> - if (!pskb_may_pull(skb, sizeof(struct pppoe_hdr)))
> + if (!pskb_may_pull(skb, PPPOE_SES_HLEN))
> goto drop;
>
> ph = pppoe_hdr(skb);
> @@ -403,6 +403,10 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
> if (skb->len < len)
> goto drop;
>
> + /* drop PFC frames */
> + if (unlikely(skb->data[0] & 0x01))
> + goto drop;
Hi,
I think it would be best to add/use a #define rather than
open coding the magic value 0x01. And perhaps expanding
the comment to note that skb->data[0] is the first byte
of the PPP protocol would be nice too.
> +
> if (pskb_trim_rcsum(skb, len))
> goto drop;
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH RFC net-next v2 2/2] af_packet: Add port specific handling for HSR
From: Willem de Bruijn @ 2026-04-06 14:47 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, Willem de Bruijn
Cc: netdev, (JC), Jayachandran, David S. Miller, Andrew Lunn,
Chintan Vankar, Danish Anwar, Daolin Qiu, Eric Dumazet,
Felix Maurer, Jakub Kicinski, Paolo Abeni, Richard Cochran,
Simon Horman, Raghavendra, Vignesh, Bajjuri, Praneeth,
TK, Pratheesh Gangadhar, Muralidharan, Neelima
In-Reply-To: <20260402163237.EIE16Pj_@linutronix.de>
Sebastian Andrzej Siewior wrote:
> Hi Willem,
>
> On 2026-03-24 17:38:21 [+0100], To Willem de Bruijn wrote:
> > On 2026-03-19 12:27:57 [-0400], Willem de Bruijn wrote:
> > >
> > > Right, so this is simple without hardware offload. Does this HW
> > > offload exist, or is this aspirational. At least for infrequent PTP
> > > it does not sound important.
> >
> > The snippet below was for the icssg driver as-is and it works with
> > updated firmware to ignore PTP packets while HW offloading is enabled.
> …
> > With the skb_ext I had, the mechanism was mostly the same but it relied
> > only on the skb_ext data. Now it has to look at skb->mark.
>
> Had you so time think about it? The proposed skb->mark solution kind of
> works but feels hacky.
> The version with skb_ext does touch packet's code but it is self
> contained and does not slowdown the !HSR+PTP case since the compare
> conditions are NOPed.
> How do we move forward here?
So the requirement is for a communication path between userspace and
the driver over packet sockets.
Existing options that work for both rx and tx are
- in-band: a packet header or footer
- mark, metadata
- maybe: vlan tags
These require changes in the HSR driver to use them, but no changes in
the protocol independent core logic, which includes packet sockets.
As I mentioned before we cannot sprinkle protocol specific code
throughout protocol independent core code. That quickly leads to an
unmaintainable mess. PTP over HSR is a particular small niche case,
nowhere near first in line to get an exception to this guideline.
One perhaps interesting Rx only option I had missed before is
SOF_TIMESTAMPING_OPT_PKTINFO. Would that give you the original
device ifindex today?
If so, we now only have to consider the Tx path to the HSR driver
(the Tx path directly to the other drivers do not need this metadata).
I'm not convinced that it is hard to come up with a way to send
a packet to the HSR driver with an optional header or footer or
vlan data (or skb->protocol perhaps?) that cannot be
differentiated from other traffic arriving at that ndo_start_xmit.
If all this fails, we can look into a protocol independent approach
to passing other metadata in packet sockets. to/from skb_ext or cb[],
say.
But at this point I see enough options that do not require changes
to packet sockets.
To get back to the simplest approach: skb->mark. Is there any
concrete risk that on this path that would conflict with other
uses of that field? If packet sockets inject directly into this
driver (possibly even with PACKET_QDISC_BYPASS)?
^ permalink raw reply
* Re: [PATCH net-next v5 00/10] Decouple receive and transmit enablement in team driver
From: Jakub Kicinski @ 2026-04-06 14:44 UTC (permalink / raw)
To: Marc Harvey
Cc: Jiri Pirko, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Shuah Khan, Simon Horman, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260406-teaming-driver-internal-v5-0-e8a3f348a1c5@google.com>
On Mon, 06 Apr 2026 03:03:36 +0000 Marc Harvey wrote:
> Allow independent control over receive and transmit enablement states
> for aggregated ports in the team driver.
>
> The motivation is that IEE 802.3ad LACP "independent control" can't
> be implemented for the team driver currently. This was added to the
> bonding driver in commit 240fd405528b ("bonding: Add independent
> control state machine").
>
> This series also has a few patches that add tests to show that the old
> coupled enablement still works and that the new decoupled enablement
> works as intended (4, 5, and 10).
>
> There are three patches with small fixes as well, with the goal of
> making the final decoupling patch clearer (1, 2, and 3).
activebackup:
TAP version 13
1..1
# overriding timeout to 2400
# selftests: drivers/net/team: teamd_activebackup.sh
# Setting up two-link aggregation for runner activebackup
# Teamd version is: teamd 1.32
# Conf files are /tmp/tmp.ydjNK9Um7H and /tmp/tmp.xZuc3cWbN0
# This program is not intended to be run as root.
# This program is not intended to be run as root.
# Created team devices
# Teamd PIDs are 21457 and 21461
# exec of "ip link set eth0 up" failed: No such file or directory
# exec of "ip link set eth0 up" failed: No such file or directory
# exec of "ip link set eth1 up" failed: No such file or directory
# exec of "ip link set eth1 up" failed: No such file or directory
# PING fd00::2 (fd00::2) 56 data bytes
# 64 bytes from fd00::2: icmp_seq=1 ttl=64 time=0.753 ms
#
# --- fd00::2 ping statistics ---
# 1 packets transmitted, 1 received, 0% packet loss, time 0ms
# rtt min/avg/max/mdev = 0.753/0.753/0.753/0.000 msPacket count for test_team2 was 0
# Waiting for eth0 in ns2-lZ0gqd to stop receiving
# Packet count for eth0 was 0Packet count for eth0 was 0
# Packet count for eth1 was 0
# Waiting for eth1 in ns2-lZ0gqd to stop receiving
# Packet count for eth1 was 0Packet count for eth0 was 0
# Packet count for eth1 was 0
# TEST: teamd active backup runner test [FAIL]
# Traffic did not reach team interface in NS2.
# Tearing down two-link aggregation
# Failed to kill daemon: Timer expired
# Failed to kill daemon: Timer expired
# Sending sigkill to teamd for test_team1
# rm: cannot remove '/var/run/teamd/test_team1.pid': No such file or directory
# rm: cannot remove '/var/run/teamd/test_team1.sock': No such file or directory
# Sending sigkill to teamd for test_team2
# rm: cannot remove '/var/run/teamd/test_team2.pid': No such file or directory
# rm: cannot remove '/var/run/teamd/test_team2.sock': No such file or directory
not ok 1 selftests: drivers/net/team: teamd_activebackup.sh # exit=1
transmit_failover:
TAP version 13
1..1
# overriding timeout to 2400
# selftests: drivers/net/team: transmit_failover.sh
# Error: ipv6: address not found.
# Setting team in ns2-yxjiUo to mode roundrobin
# Error: ipv6: address not found.
# Setting team in ns1-Jht6kA to mode broadcast
# Packet count for eth0 was 0
# Packet count for eth1 was 0
# Packet count for eth0 was 0
# Packet count for eth1 was 0
# Packet count for eth0 was 0
# Packet count for eth1 was 0
# TEST: Failover of 'broadcast' test [FAIL]
# eth0 not transmitting when both links enabled
# Setting team in ns1-Jht6kA to mode roundrobin
# Packet count for eth0 was 0
# Packet count for eth1 was 0
# Packet count for eth0 was 0
# Packet count for eth1 was 0
# Packet count for eth0 was 0
# Packet count for eth1 was 0
# TEST: Failover of 'roundrobin' test [FAIL]
# eth0 not transmitting when both links enabled
# Setting team in ns1-Jht6kA to mode random
# Packet count for eth0 was 0
# Packet count for eth1 was 0
# Packet count for eth0 was 0
# Packet count for eth1 was 0
# Packet count for eth0 was 0
# Packet count for eth1 was 0
# TEST: Failover of 'random' test [FAIL]
# eth0 not transmitting when both links enabled
not ok 1 selftests: drivers/net/team: transmit_failover.sh # exit=1
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration
From: Carlo Szelinsky @ 2026-04-06 14:43 UTC (permalink / raw)
To: Andrew Lunn, Oleksij Rempel
Cc: Kory Maincent, Andrew Lunn, Heiner Kallweit, Russell King,
Jakub Kicinski, David S . Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, netdev, linux-kernel, Carlo Szelinsky
In-Reply-To: <3597433c-ce26-43c6-9a5f-e942a3db5340@lunn.ch>
Hi Andrew, Oleksij,
Thanks for pushing me in the right direction here.
So if I understand correctly, I should move the PSE control lookup
from fwnode_mdiobus_register_phy() into phy_probe(). That way the PHY
just defers like any other device if the PSE controller isn't there
yet, and the bus scan keeps going for the other PHYs.
I checked and bus_probe_device() is void, so device_add() won't fail
even if probe defers. And once the PSE module loads, the deferred
probe retry should kick in and claim the regulator before the 30s
cleanup runs. If the module never loads, the regulator cleanup is
actually the right thing to do safety-wise. So no need for the
admin_state_synced workaround or the lazy resolution stuff -
deferred probe just handles it.
Unlike lazy resolution, this also doesn't break notifications, so
PSE is acquired during probe, not on first ethtool access.
Does that sound like what you had in mind?
Cheers,
Carlo
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] bpf-timestamp: convert to push-level granularity
From: Willem de Bruijn @ 2026-04-06 14:38 UTC (permalink / raw)
To: Jason Xing, Willem de Bruijn
Cc: davem, edumazet, kuba, pabeni, horms, willemb, martin.lau, netdev,
bpf, Jason Xing
In-Reply-To: <CAL+tcoDuSyQdR83C-07bUpJfYdnrkkcA8gO+0qKZM8PTbiFofA@mail.gmail.com>
Jason Xing wrote:
> On Mon, Apr 6, 2026 at 10:17 AM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > Jason Xing wrote:
> > > From: Jason Xing <kernelxing@tencent.com>
> > >
> > > 1. Design of send-level granularity
> > > Originally, socket timestamping was designed to support tracing each
> > > sendmsg instead of per packet because application needs to issue
> > > multiple extra recvmsg() calls to get the skbs carrying the timestamp
> > > one by one if application chooses tag with different tags(SCHED/DRV/ACK).
> > > It's an obvious huge burden if the application expects to see a finer
> > > grained behavior.
> > > Another point I mentioned a bit in Netdev 0x19[1], supposing the amount of
> > > data that application tries to transfer at one time is split into 100
> > > smaller packets, recording the last skb's timestamps (SCHED/DRV/HARDWARE)
> > > is no longer meaningful because at the moment timestamping only records
> > > 1/100 packets. In this case, only the delta between when to send and when
> > > to ack matters.
> > >
> > > 2. Known missing tag issues in TCP
> > > A critically important thing is that we can miss tagging the last packet
> > > in a few conditions as the patch 3/4 explains. That means we lose track
> > > of the send syscall. Digging into more into how tcp_sendmsg_locked works,
> > > I found it's not feasible to successfully identify the last skb before
> > > push functions get called. With that said, if we want to make the feature
> > > better to cover all of these cases, we inevitably needs to place
> > > tcp_bpf_tx_timestamp() function before each push function.
> > >
> > > 3. Practice at Tencent
> > > In production, we have a version that applies the packet basis policy to
> > > do the exhaustive profiling of each flow for months in order to:
> > > 1) 100% make sure to capture the jitter event. No sampling.
> > > 2) observe the performance, find the bottleneck and improve it.
> > > We're still collecting data and investigating how it helps us in all the
> > > potential aspects before upstreaming. My personal perspective on this is
> > > to replace tcpdump eventually. It's worth mentioning tcpdump no longer
> > > satisfies our micro observation in modern data center.
> > >
> > > 4. The tendency toward finer-grained observability
> > > As we're aware that there are already many various bpf scripts trying to
> > > implement the fine grained monitor of the packets, it's an unstoppable
> > > tendency for the future observability. We're faced with so many latency
> > > reports (like jitter, perf degradation) on a daily basis. Getting the
> > > root cause of each report is exactly what we pursue.
> > > After we know which request causes the problem, if it belongs to kernel,
> > > we will dig into the packet behavior with more useful information
> > > included. This is the process of tracing down the jitter problem.
> > > Likewise, in BPF timestamping that mitigates the impact of calling extra
> > > syscalls, breaking the coarse granularity into smaller ones is a first
> > > good way to go. It shouldn't be the burden like before especially it's
> > > independent of application.
> > >
> > > 5. Details of the series
> > > Now it's time to convert BPF timestamping feature into push-level
> > > granularity by only recording the last skb in each push function, which
> > > is quite similar to how we previously treat each send syscall.
> > > Regarding each push function as a whole, we only care about
> > > the last skb from each push since the skb can be chunked into different
> > > smaller packets. BPF scripts like progs/net_timestamping.c has the
> > > ability to trace each tagged skb and calculate the latency:
> > > 1) delta between send and each tagged skb in tcp_sendmsg_locked()
> > > 2) delta between SCHED/DRV/ACK. Three timestamps are also correlated
> > > with the sendmsg time.
> > >
> > > In conclusion, push-level is more of a compromise approach which covers
> > > those corner cases and further enhances the capabilities (like a finer
> > > grained observation of jitter and performance issues).
> >
> > # push-level design
> >
> > It it significantly less intuitive than per-syscall, which is under
> > user control. Or even than per-packet. As a fix for missing timestamps
> > I understand these two extensions, even with the unintended side
> > effect of reporting many unnecessary extra skbs in the common case.
> > As a model to advocate for, less so.
>
> Thanks for your review!
>
> Fair enough. One mode of our internal kernel module directly hijacks
> tcp_skb_entail() that handles the last skb of this skb if
> fragmentation happens.
>
> >
> > Would it help if all skbs from the same sendmsg() can still be
> > identified as common from the same syscall? That allows the user
>
> I have to add more comments about push level:
> the last skb from each push function will always be correlated with
> its own sendmsg. With the help of BPF_SOCK_OPS_TSTAMP_SENDMSG_CB, bpf
> script can do so.
>
> > to discard all but the last one (if they wish)
>
> Oh, I just replied with another reply. Let's start the discussion here.
>
> It would be great if we have a definite finer grained observability.
>
> >
> >
> > # ABI changes
> >
> > For SO_TIMESTAMPING we would not be able to make this change
> > unconditionally as the behavior change would break existing
> > application expectations.
>
> Right.
>
> >
> > That is why historically we have guarded new behabvior behind new
> > TS options flags.
> >
> > The same may be true for BPF.
>
> How about adding a socket option for a per packet mode, say,
> BPF_SOCK_OPS_TSTAMP_TCP_PACKET_CB around tcp_skb_entail() which works
> very similarly to
> BPF_SOCK_OPS_TSTAMP_SENDMSG_CB. After that, users have a standalone
> option to decide whether to trace all the skbs from the sendmsg.
>
> If so, the origin BPF timestamping that works exactly like socket
> timestamping is the best effort (we don't 100% guarantee the timestamping
> feature captures every sendmsg call). With the new socket option
> involved, we provide a finer grained vision without harming users who
> favor the origin design with those two issues resolved.
>
> A kind reminder is that if the skb is fragmented, for instance, due to
> TSO being disabled, only the last smaller/child one will be monitored.
See also my reply in the other thread. Yes, per-packet may be more
informative and understandable as policy than per-push.
^ permalink raw reply
* Re: [PATCH net-next] ip6_tunnel: use generic for_each_ip_tunnel_rcu macro
From: Simon Horman @ 2026-04-06 14:38 UTC (permalink / raw)
To: Yue Haibing; +Cc: davem, dsahern, edumazet, kuba, pabeni, netdev, linux-kernel
In-Reply-To: <20260403084619.4107978-1-yuehaibing@huawei.com>
On Fri, Apr 03, 2026 at 04:46:19PM +0800, Yue Haibing wrote:
> Remove the locally defined for_each_ip6_tunnel_rcu macro and use
> the generic for_each_ip_tunnel_rcu from linux/if_tunnel.h instead.
>
> This eliminates code duplication and ensures consistency across
> the kernel tunnel implementations.
>
> Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
> ---
> net/ipv6/ip6_tunnel.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] bpf-timestamp: keep track of the skb when wait_for_space occurs
From: Willem de Bruijn @ 2026-04-06 14:37 UTC (permalink / raw)
To: Jason Xing, Willem de Bruijn
Cc: davem, edumazet, kuba, pabeni, horms, willemb, martin.lau, netdev,
bpf, Jason Xing, Yushan Zhou
In-Reply-To: <CAL+tcoB94=ptFB-acU3nAK_MqW74DV0MQUVvvV3nbQ7Zc6zSZw@mail.gmail.com>
Jason Xing wrote:
> On Mon, Apr 6, 2026 at 10:28 AM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > Jason Xing wrote:
> > > From: Jason Xing <kernelxing@tencent.com>
> > >
> > > The patch is the 1/2 part of push-level granularity feature.
> > >
> > > Tag the skb in tcp_sendmsg_locked() when wait_for_space occurs even
> > > though it might not carry the last byte of the sendmsg.
> > >
> > > Prior to the patch, BPF timestamping cannot cover this case:
> > > The following steps reproduce this:
> > > 1) skb A is the current last skb before entering wait_for_space process
> > > 2) tcp_push() pushes A without any tag
> > > 3) A is transmitted from TCP to driver without putting any skb carrying
> > > timestamps in the error queue, like SCHED, DRV/HARDWARE.
> > > 4) sk_stream_wait_memory() sleeps for a while and then returns with an
> > > error code. Note that the socket lock is released.
> > > 5) skb A finally gets acked and removed from the rtx queue.
> > > 6) continue with the rest of tcp_sendmsg_locked(): it will jump to(goto)
> > > 'do_error' label and then 'out' label.
> > > 7) at this moment, skb A turns out to be the last one in this send
> > > syscall, and miss the following tcp_bpf_tx_timestamp() opportunity
> > > before the final tcp_push()
> > > 8) BPF script fails to see any timestamps this time
> > >
> > > Signed-off-by: Yushan Zhou <katrinzhou@tencent.com>
> > > Signed-off-by: Jason Xing <kernelxing@tencent.com>
> > > ---
> > > net/ipv4/tcp.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> > > index c603b90057f6..7d030a11d004 100644
> > > --- a/net/ipv4/tcp.c
> > > +++ b/net/ipv4/tcp.c
> > > @@ -1400,9 +1400,11 @@ int tcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_t size)
> > > wait_for_space:
> > > set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
> > > tcp_remove_empty_skb(sk);
> > > - if (copied)
> > > + if (copied) {
> > > + tcp_bpf_tx_timestamp(sk);
> > > tcp_push(sk, flags & ~MSG_MORE, mss_now,
> > > TCP_NAGLE_PUSH, size_goal);
> >
> > Now the number of skbs that will be tracked will be unpredictable,
> > varying based on memory pressure.
>
> Right, I put some effort into writing a selftests to check how many
> push functions get called at one time and failed to do so.
>
> >
> > That sounds hard to use to me. Especially if these extra pushes
> > cannot be identified as such.
> >
> > Perhaps if all skbs from the same sendmsg call can be identified,
> > that would help explain pattern in data resulting from these
> > uncommon extra data points.
>
> You meant move tcp_bpf_tx_timestamp before tcp_skb_entail()? That is
> close to packet basis without considering fragmentation of skb :)
No, I meant somehow in the notification having a way to identify all
the skbs belonging to the same sendmsg call, to allow filtering on
that. But I also don't immediately see how to do that (without adding
yet another counter say).
Right now, push-based seems rather arbitrary to me, informed more by
technical limitations than a clear design. Perhaps per-packet makes
more sense, esp. since BPF calls are cheap (compared to the other
errqueue mechanism).
^ permalink raw reply
* Re: [PATCH net-next] ipv6: sit: remove redundant ret = 0 assignment
From: Simon Horman @ 2026-04-06 14:35 UTC (permalink / raw)
To: Yue Haibing; +Cc: davem, dsahern, edumazet, kuba, pabeni, netdev, linux-kernel
In-Reply-To: <20260403084402.4105936-1-yuehaibing@huawei.com>
On Fri, Apr 03, 2026 at 04:44:02PM +0800, Yue Haibing wrote:
> The variable ret is initialized to 0 when it is defined
> and is not modified before copy_to_user().
>
> Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* [BUG] net/sched: skb leak with HTB + fq_codel on packet drops
From: Damilola Bello @ 2026-04-06 14:29 UTC (permalink / raw)
To: netdev, linux-kernel
Description:
Using fq_codel as a child qdisc under HTB results in continuous growth
of skbuff_head_cache objects when packet drops occur. Memory is not
freed even after traffic stops, and the system can eventually run out
of memory.
Regression:
- Works on: 6.18.16
- Fails on: 6.19.x (tested on 6.19.10-200.fc43)
Environment:
- Kernel: 6.19.10-200.fc43
- Distro: Fedora 43
- NICs: ens2f0np0, ens2f1np1
- GRO/GSO/TSO: disabled
Reproduction:
#!/bin/sh
DEVS="ens2f0np0 ens2f1np1"
for DEV in $DEVS; do
tc qdisc del dev $DEV root 2>/dev/null
tc qdisc add dev $DEV root handle 1: htb default 10
tc class add dev $DEV parent 1: classid 1:10 htb rate 100mbit
tc qdisc add dev $DEV parent 1:10 handle 10: fq_codel
tc filter add dev $DEV parent 1: matchall flowid 1:10
done
Generate traffic exceeding 100mbit (e.g., iperf3) to force drops.
Observed behavior:
- fq_codel reports packet drops
- skbuff_head_cache grows continuously:
- grep skbuff_head_cache /proc/slabinfo
skbuff_head_cache 12144512 ... (continues increasing)
- skbuff_head_cache doesn't clear off even after traffic stops.
Key observations:
- Leak only occurs when fq_codel drops packets
- No drops -> no leak
- HTB + pfifo -> no leak
- fq_codel as root qdisc -> no leak
- cake as root qdisc -> no leak
- The leak only occurs when fq_codel (or cake) is used as a child
qdisc under HTB
Expected behavior:
- SKBs should be freed after drops
- skbuff_head_cache should stabilize after traffic stops
Additional notes:
- This appears related to skb lifetime/accounting during drop handling
in the HTB + child qdisc path
- Possibly related to GRO/GSO interaction or skb segmentation handling
Request:
- Is this a known regression?
- Any guidance on further debugging or identifying the offending commit?
^ permalink raw reply
* Re: [PATCH v3 net-next] net: use get_random_u{16,32,64}() where appropriate
From: David CARLIER @ 2026-04-06 14:28 UTC (permalink / raw)
To: Matthieu Baerts
Cc: Jakub Kicinski, David S . Miller, Eric Dumazet, Paolo Abeni,
Andrew Lunn, Simon Horman, Ilya Dryomov, Johannes Berg,
Mat Martineau, Geliang Tang, Aaron Conole, Ilya Maximets,
Marcelo Ricardo Leitner, Xin Long, Jon Maloy, netdev, ceph-devel,
linux-wireless, mptcp, dev, linux-sctp, tipc-discussion,
linux-kernel
In-Reply-To: <268a9951-c1a6-4b24-8578-0a8bf4b957a3@kernel.org>
Hi Mathieu yes this is indeed a valid point, will address is for next
time. Cheers
On Mon, 6 Apr 2026 at 15:13, Matthieu Baerts <matttbe@kernel.org> wrote:
>
> Hi David,
>
> On 05/04/2026 17:48, David Carlier wrote:
> > Use the typed random integer helpers instead of
> > get_random_bytes() when filling a single integer variable.
> > The helpers return the value directly, require no pointer
> > or size argument, and better express intent.
>
> Regarding the modifications in net/mptcp, it looks good to me:
>
> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> # net/mptcp
>
> > Skipped sites writing into __be16 fields (netdevsim) where
> > a direct assignment would trigger sparse endianness warnings.
>
> Note that the AI reviews are mentioning that auth->client_challenge from
> net/ceph/auth_x.c is declared as __le64, and it might then also cause
> sparse warnings:
>
> https://sashiko.dev/#/patchset/20260405154816.4774-1-devnexen%40gmail.com
>
>
> It looks like they are right:
>
> $ make C=1 net/ceph/auth_x.o
> net/ceph/auth_x.c:574:40: warning: incorrect type in assignment (different base types)
> net/ceph/auth_x.c:574:40: expected restricted __le64 [usertype] client_challenge
> net/ceph/auth_x.c:574:40: got unsigned long long
>
>
> Note that the Netdev CI currently doesn't check sparse warnings:
>
> https://github.com/linux-netdev/nipa/issues/76
>
> Cheers,
> Matt
> --
> Sponsored by the NGI0 Core fund.
>
^ permalink raw reply
* Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Jim Mattson @ 2026-04-06 14:23 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet, linux-kernel, kvm, Asit Mallick,
Tao Zhang, bpf, netdev, linux-doc, chao.gao
In-Reply-To: <20260404034954.t7iapenzvhdpagxp@desk>
On Fri, Apr 3, 2026 at 8:50 PM Pawan Gupta
<pawan.kumar.gupta@linux.intel.com> wrote:
>
> On Fri, Apr 03, 2026 at 07:21:02PM -0700, Jim Mattson wrote:
> > On Fri, Apr 3, 2026 at 5:22 PM Pawan Gupta
> > <pawan.kumar.gupta@linux.intel.com> wrote:
> > >
> > > On Fri, Apr 03, 2026 at 04:39:54PM -0700, Jim Mattson wrote:
> > > > > Since cloud providers have greater control over userspace, the decision to
> > > > > use BHI_DIS_S or not can be left to them. KVM would simply follow what it
> > > > > is asked to do by the userspace.
> > > >
> > > > I feel like we've gone over this before, but if userspace tells KVM
> > > > not to enable BHI_DIS_S, how do we inform Windows that it needs to do
> > > > the longer clearing sequence, despite the fact that the virtual CPU is
> > > > masquerading as Ice Lake?
> > >
> > > IMO, if an OS is allergic to a hardware mitigation, and is also aware that
> > > it is virtualized, it should default to a sw mitigation that works everywhere.
> >
> > Agreed. So, without any information to the contrary, VMs should assume
> > the long BHB clearing sequence is required.
> >
> > Returning to my earlier comment, the test should be:
> >
> > + if (cpu_feature_enabled(X86_FEATURE_BHI_CTRL) ||
> > cpu_feature_enabled(X86_FEATURE_HYPERVISOR)) {
> > + bhb_seq_outer_loop = 12;
> > + bhb_seq_inner_loop = 7;
> > + }
>
> To be clear, my comment was for an OS that doesn't want BHI_DIS_S
> under-the-hood with virtual-SPEC_CTRL. Linux doesn't have that problem,
> hardware mitigation on Linux is perfectly okay.
Today, BHI_DIS_S under-the-hood isn't offered. If the hypervisor
doesn't offer the paravirtual mitigation MSRs, the guest must assume
that the hypervisor will not set BHI_DIS_S on its behalf.
> Without virtual-SPEC_CTRL, the problem set is limited to guests that
> migrate accross Alder Lake generation CPUs. As you mentioned the change in
> MAXPHYADDR makes it unlikely.
I have been unable to make a compelling argument for not crossing this
boundary. The only applications I can point to that are broken by the
missing reserved bits are (nested) hypervisors using shadow-paging.
Since both nVMX and nSVM support TDP, the niche cache isn't a concern.
There are compelling business reasons to support seamless migration
from pre-Alder Lake to post-Alder Lake. If you know of any other
applications that will fail with a mis-emulated smaller MAXPHYADDR,
please let me know.
> With virtual-SPEC_CTRL support, guests that fall into the subset that
> migrate inspite of MAXPHYADDR change would also be mitigated. Then, on top
> of hardware mitigation, deploying the long sequence in the guest would
> incur a significant performance penalty for no good reason.
Yes, but the guest needs a way to determine whether the hypervisor
will do what's necessary to make the short sequence effective. And, in
particular, no KVM hypervisor today is prepared to do that.
When running under a hypervisor, without BHI_CTRL and without any
evidence to the contrary, the guest must assume that the longer
sequence is necessary. At the very least, we need a CPUID or MSR bit
that says, "the short BHB clearing sequence is adequate for this
vCPU."
^ permalink raw reply
* Re: [PATCH net v2] bridge: cfm: reject invalid CCM interval at configuration time
From: Simon Horman @ 2026-04-06 14:15 UTC (permalink / raw)
To: Xiang Mei
Cc: netdev, bridge, razor, idosch, davem, edumazet, pabeni, bestswngs
In-Reply-To: <20260405000324.548623-1-xmei5@asu.edu>
On Sat, Apr 04, 2026 at 05:03:24PM -0700, Xiang Mei wrote:
> ccm_tx_work_expired() re-arms itself via queue_delayed_work() using
> the configured exp_interval converted by interval_to_us(). When
> exp_interval is BR_CFM_CCM_INTERVAL_NONE or out of range,
> interval_to_us() returns 0, causing the worker to fire immediately in
> a tight loop that allocates skbs until OOM.
>
> Fix this by validating exp_interval at configuration time:
>
> - Constrain IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL to [1, 7] in the
> netlink policy so userspace cannot set an invalid value.
>
> - Reject starting CCM TX in br_cfm_cc_ccm_tx() when exp_interval has
> not yet been configured (defaults to 0 from kzalloc).
>
> Fixes: a806ad8ee2aa ("bridge: cfm: Kernel space implementation of CFM. CCM frame TX added.")
> Reported-by: Weiming Shi <bestswngs@gmail.com>
> Signed-off-by: Xiang Mei <xmei5@asu.edu>
> ---
> v2: Move validation out of the datapath and into configuration
Thanks for the update.
Reviewed-by: Simon Horman <horms@kernel.org>
...
^ permalink raw reply
* Re: [PATCH v3 net-next] net: use get_random_u{16,32,64}() where appropriate
From: Matthieu Baerts @ 2026-04-06 14:13 UTC (permalink / raw)
To: David Carlier
Cc: Jakub Kicinski, David S . Miller, Eric Dumazet, Paolo Abeni,
Andrew Lunn, Simon Horman, Ilya Dryomov, Johannes Berg,
Mat Martineau, Geliang Tang, Aaron Conole, Ilya Maximets,
Marcelo Ricardo Leitner, Xin Long, Jon Maloy, netdev, ceph-devel,
linux-wireless, mptcp, dev, linux-sctp, tipc-discussion,
linux-kernel
In-Reply-To: <20260405154816.4774-1-devnexen@gmail.com>
Hi David,
On 05/04/2026 17:48, David Carlier wrote:
> Use the typed random integer helpers instead of
> get_random_bytes() when filling a single integer variable.
> The helpers return the value directly, require no pointer
> or size argument, and better express intent.
Regarding the modifications in net/mptcp, it looks good to me:
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> # net/mptcp
> Skipped sites writing into __be16 fields (netdevsim) where
> a direct assignment would trigger sparse endianness warnings.
Note that the AI reviews are mentioning that auth->client_challenge from
net/ceph/auth_x.c is declared as __le64, and it might then also cause
sparse warnings:
https://sashiko.dev/#/patchset/20260405154816.4774-1-devnexen%40gmail.com
It looks like they are right:
$ make C=1 net/ceph/auth_x.o
net/ceph/auth_x.c:574:40: warning: incorrect type in assignment (different base types)
net/ceph/auth_x.c:574:40: expected restricted __le64 [usertype] client_challenge
net/ceph/auth_x.c:574:40: got unsigned long long
Note that the Netdev CI currently doesn't check sparse warnings:
https://github.com/linux-netdev/nipa/issues/76
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration
From: Oleksij Rempel @ 2026-04-06 14:12 UTC (permalink / raw)
To: Andrew Lunn
Cc: Carlo Szelinsky, Kory Maincent, Andrew Lunn, Heiner Kallweit,
Russell King, Jakub Kicinski, David S . Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, netdev, linux-kernel
In-Reply-To: <1df8b470-2449-418d-a4a8-9cd929ced463@lunn.ch>
On Mon, Apr 06, 2026 at 02:22:16PM +0200, Andrew Lunn wrote:
> > The core question, do we need PSE for PHY functionality?
>
> I don't think the PHY should require PSE in order to send/receive
> frames. If the PSE is not supplying power, the link peer is probably
> off, but that is not so different from the cable being unplugged.
>
> > We can make a step back and re-evaluate - what functionality and what
> > order is actually required to find potentially better implementation.
> >
> > We have a lot of current flowing over wires, budget and port
> > prioritization issues, things which may damage HW if done not correctly.
> > With other word, if we do not have properly operational environment
> > providing system specific policies, it is better to run safe
> > configuration - all ports/regulators are off.
> >
> > This means:
> > - PSE controller driver should be registered as early as possible,
> > without caring about existence of PHYs, ports or network interfaces.
> > And configure ports in to default safe operation - off. Accept we
> > have some controller/firmware which would care about safety.
>
> Don't most PSE have I2C or SPI interfaces? So they have a different
> life cycle to PHYs, ports or netdevs. Only PSEs which are embedded
> within a PHY, on an MDIO bus, will have a closely linked life
> cycle. But do such devices exist?
i'm not aware of any.
> As soon as the PSE probes with all the resources it needs, and can
> impose a safe default setting. And that can be independent of PHY and
> netdev. I _think_ we only need the netdev for configuration, since
> ethtool addresses netdev's. There would only be issues with user
> space listening to udev creation events, it knows the PSE exists, but
> it has no way to access it until the netdev is created.
Ack. netdev is for configuration as virtual representation of PSE PI. And it
is easier to assign corresponding interface for the LLDP.
We do not really care about the PHY; it just happens to represent the
port at the farthest end described in the Device Tree.
> > - as soon as we have all needed components, we can start provide
> > controllable interfaces to serve external consumers.
>
> Yep.
>
> > If we decouple PSE and PHY registration (and we probably will need to do
> > it some day), we would need to have own implementation of deferred
> > probing in the PSE core. Event driven or by polling - which sounds not
> > like very good idea. Pick your poison...
>
> I don't see why. Maybe i'm missing something. We have two cases:
>
> 1) PSE probes first. When the PHY looks up the PSE, it exists, and it
> is passed a handle to the PSE.
>
> 2) PHY probes first. The PSE core returns EPROBE_DEFFER, and the PHY
> will try again later.
>
> I don't think there is any chicken/egg problems.
Ack, i guess it is optimization problem.
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v10 net-next 3/5] psp: add a new netdev event for dev unregister
From: Daniel Zahka @ 2026-04-06 14:12 UTC (permalink / raw)
To: Wei Wang, netdev, Jakub Kicinski, Willem de Bruijn, David Wei,
Andrew Lunn, David S . Miller, Eric Dumazet, Simon Horman
Cc: Wei Wang
In-Reply-To: <20260405055853.3285534-4-weibunny.kernel@gmail.com>
On 4/5/26 1:58 AM, Wei Wang wrote:
> From: Wei Wang <weibunny@fb.com>
>
> Add a new netdev event for dev unregister and handle the removal of this
> dev from psp->assoc_dev_list, upon the first dev-assoc operation.
>
> Signed-off-by: Wei Wang <weibunny@fb.com>
> ---
...
> +static bool psp_notifier_registered;
> +
> +/**
> + * psp_attach_netdev_notifier() - register netdev notifier on first use
> + *
> + * Register the netdevice notifier when the first device association
> + * is created. In many installations no associations will be created and
> + * the notifier won't be needed.
> + *
> + * Must be called without psd->lock held, due to lock ordering:
> + * rtnl_lock -> psd->lock (the notifier callback runs under rtnl_lock
> + * and takes psd->lock).
> + */
> +int psp_attach_netdev_notifier(void)
> +{
> + int err = 0;
> +
> + if (READ_ONCE(psp_notifier_registered))
> + return 0;
> +
> + mutex_lock(&psp_devs_lock);
> + if (!psp_notifier_registered) {
> + err = register_netdevice_notifier(&psp_netdev_notifier);
> + if (!err)
> + WRITE_ONCE(psp_notifier_registered, true);
> + }
> + mutex_unlock(&psp_devs_lock);
> +
> + return err;
> +}
> +
This looks like an abuse of the psp_devs_lock to provide mutual
exclusion on psp_notifier_registered, which has the undesirable property
of establishing a lock dependency from psp_devs_lock -> rtnl_lock.
Perhaps a dedicated mutex would be cleaner.
>
> +/**
> + * Non-admin version of psp_device_get_locked() + psp_attach_netdev_notifier()
> + * only used for dev-assoc.
> + */
> +int psp_device_get_locked_dev_assoc(const struct genl_split_ops *ops,
> + struct sk_buff *skb, struct genl_info *info)
kdoc open, but not a kdoc comment.
Minor comments, otherwise:
Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com>
^ permalink raw reply
* Re: [PATCH iwl-next] ixgbe: use ktime_get_real_ns() in ixgbe_ptp_reset()
From: Simon Horman @ 2026-04-06 14:07 UTC (permalink / raw)
To: Keller, Jacob E
Cc: Loktionov, Aleksandr, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L, netdev@vger.kernel.org, Marcin Szycik
In-Reply-To: <DS0PR11MB7579E948B1DAEF3E8D28C1EBD65EA@DS0PR11MB7579.namprd11.prod.outlook.com>
On Fri, Apr 03, 2026 at 08:26:20PM +0000, Keller, Jacob E wrote:
>
>
> > -----Original Message-----
> > From: Simon Horman <horms@kernel.org>
> > Sent: Friday, April 3, 2026 6:12 AM
> > To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> > Cc: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> > <anthony.l.nguyen@intel.com>; netdev@vger.kernel.org; Keller, Jacob E
> > <jacob.e.keller@intel.com>; Marcin Szycik <marcin.szycik@linux.intel.com>
> > Subject: Re: [PATCH iwl-next] ixgbe: use ktime_get_real_ns() in
> > ixgbe_ptp_reset()
> >
> > On Fri, Apr 03, 2026 at 02:10:38PM +0100, Simon Horman wrote:
> > > On Fri, Mar 27, 2026 at 08:30:39AM +0100, Aleksandr Loktionov wrote:
> > > > From: Jacob Keller <jacob.e.keller@intel.com>
> > > >
> > > > Replace ktime_to_ns(ktime_get_real()) with the direct equivalent
> > > > ktime_get_real_ns() in ixgbe_ptp_reset(). Using the combined helper
> > > > avoids the unnecessary intermediate ktime_t variable and makes the
> > > > intent clearer.
> > > >
> > > > Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> > > > Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> > > > Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com>
> > >
> > > Reviewed-by: Simon Horman <horms@kernel.org>
> > >
> > > FWIIW, this pattern also seems to exist in e1000e, ixgbe and igb (twice).
> >
> > Of course, with this patch applied it's not present in ixgbe anymore :^)
>
> Right. Given that e1000e and igb are basically on life support only, I
> would limit touching them unless we have relevant work to do in that area
> in the future.
Sure, that is fine by me.
^ permalink raw reply
* Re: [PATCH iwl-next] ixgbe: fix ITR value overflow in adaptive interrupt throttling
From: Simon Horman @ 2026-04-06 14:06 UTC (permalink / raw)
To: Loktionov, Aleksandr
Cc: intel-wired-lan@lists.osuosl.org, Nguyen, Anthony L,
netdev@vger.kernel.org
In-Reply-To: <IA3PR11MB8986472BF64AFBF2191A381EE55EA@IA3PR11MB8986.namprd11.prod.outlook.com>
On Fri, Apr 03, 2026 at 04:12:02PM +0000, Loktionov, Aleksandr wrote:
>
>
> > -----Original Message-----
> > From: Simon Horman <horms@kernel.org>
> > Sent: Friday, April 3, 2026 3:19 PM
> > To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> > Cc: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> > <anthony.l.nguyen@intel.com>; netdev@vger.kernel.org
> > Subject: Re: [PATCH iwl-next] ixgbe: fix ITR value overflow in
> > adaptive interrupt throttling
> >
> > On Fri, Mar 27, 2026 at 08:30:45AM +0100, Aleksandr Loktionov wrote:
> > > ixgbe_update_itr() packs a mode flag (IXGBE_ITR_ADAPTIVE_LATENCY,
> > bit
> > > 7) and a usecs delay (bits [6:0]) into an unsigned int, then stores
> > it
> > > in ring_container->itr which is u8. Values above 0xFF wrap,
> > > corrupting both the delay and the mode-flag on the next readback.
> > >
> > > Separate the mode bits from the usecs sub-field; clamp only the
> > latter
> > > to [0, IXGBE_ITR_ADAPTIVE_LATENCY - 1] via min_t(unsigned int, ...)
> > so
> > > overflow cannot bleed into bit 7. Add a WARN_ONCE() when the raw
> > > usecs value exceeds U8_MAX so out-of-range ITR computations are
> > > visible in dmesg during development and testing.
> > >
> > > Fixes: b4ded8327fea ("ixgbe: Update adaptive ITR algorithm")
> > > Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> >
> > Somehow - perhaps because there is no m/n notation present in the []
> > in the subject - Patchwork has treated each patch in this series as
> > it's own patch-set.
> >
> > And in the case of this patch, it didn't apply - I assume because in
> > order to do so an earlier patch in the series needs to be present.
> >
> > So CI didn't run on this patch :(
>
> Good day, Simon
>
> I have a bunch of simple /* independent */ patches for submission every week.
> Whis way you'd recommend to send them to ease /* and accelerate review */ ?
>
> 1. submit one by one
> 2. submit as a batch by one git command (with the same internal main ID tag internally)
> 3. imagine a cover latter and submit as a patch-set
Hi Aleksandr,
I would suggest 3 and lean towards small batches.
^ permalink raw reply
* Re: [PATCH net-next] net: mctp: defer creation of dst after source-address check
From: Simon Horman @ 2026-04-06 13:58 UTC (permalink / raw)
To: Jeremy Kerr
Cc: Matt Johnston, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev
In-Reply-To: <20260403-dev-mctp-dst-defer-v1-1-9c2c55faf9e9@codeconstruct.com.au>
On Fri, Apr 03, 2026 at 10:24:51AM +0800, Jeremy Kerr wrote:
> Sashiko reports:
>
> > mctp_dst_from_route() increments the device reference count by calling
> > mctp_dev_hold(). When a valid route is found and dst is NULL, the
> > structure copy is bypassed and rc is set to 0.
>
> Instead of optimistically creating a dst from the final route (then
> releasing it if the saddr is invalid), perform the saddr check first.
>
> This means we don't have an unuecessary hold/release on the dev, which
> could leak if the dst pointer is NULL. No caller passes a NULL dst at
> present though (so the leak is not possible), but this is an intended
> use of mctp_dst_from_route().
>
> Fixes: 22cb45afd221 ("net: mctp: perform source address lookups when we populate our dst")
> Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: phy: add support for disabling autonomous EEE
From: Andrew Lunn @ 2026-04-06 13:56 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Florian Fainelli,
Broadcom internal kernel review list, netdev, linux-kernel
In-Reply-To: <9272c5dd653039b3def8caaea3e631c5@tipi-net.de>
> "Autonomous EEE" works for me (obviously). It kinda describes what
> happens (the PHY acts autonomously) without being tied to a specific
> vendor's marketing name.
>
> That said, I feel Russell's argument that it doesn't type well. But
> even after some walks in the woods I wasn't able to come up with a
> better name yet.
Yes, naming is hard.
> I don't think there's a meaningful use case for letting users choose
> between the two. Or is there?
This has come up before, in other context. PTP is one example, where
both the MAC and the PHY can implement it. Ideally, you want it to
happen at the PHY, it gives higher accuracy. But there are systems
where the PHY implementation is somewhat broken, and the MAC PTP gives
better results. So defaulting to PHY PTP is not always the best
option.
I would expect IEEE 802.3 EEE, with both the MAC and PHY cooperating
is better than just PHY level EEE, the system as a whole has a better
picture of what is going on, so using 802.3 EEE should be the
preference/default. But are we going to run into oddball systems where
autonomous EEE is actually better than using a somewhat broke MAC?
Andrew
^ 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