* Re: [PATCH] net/stmmac: Fix typos: 'tx_undeflow_irq' -> 'tx_underflow_irq'
From: Jakub Raczynski @ 2026-04-22 14:15 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, linux-kernel, kuba, davem, andrew+netdev, kernel-janitors,
linux-arm-kernel, linux-stm32
In-Reply-To: <f1d51362-ca8f-481a-b9c1-400ab6422686@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]
On Wed, Apr 22, 2026 at 02:47:38PM +0200, Andrew Lunn wrote:
> > I don't see anything wrong with it?
> > - naming is correct, same as stmmac_extra_stats from common.h, as it
> > wouldn't compile otherwise
> > - string length is ok, as max name length is ETH_GSTRING_LEN=32 and it is
> > not close
> > - ethtool just polls data from driver and in my tests it is ok
> > - all instances of 'undeflow' are changed
> > - 'underflow' semantic is ok, 'undeflow' is just not correct
> >
> > Please correct me if I am wrong, but imo no issues with this patch.
>
> ABI
>
> This name is published as part of the kAPI. You are changing its
> name. User space could be looking for this name, even thought it has a
> typo in it.
>
> Andrew
>
I don't think it is? This part of extra stats (struct stmmac_extra_stats) and
is not part of standard ABI from
Documentation/ABI/testing/sysfs-class-net-statistics
nor is mentioned in
Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst
These extra stats are specific to stmmac driver and most of these are more
than standard
https://www.kernel.org/doc/html/v7.0/networking/statistics.html#c.rtnl_link_stats64
This name does not exist outside stmmac driver, so while some application may
expect this (stmmac specific app), question is should this typo stick?
This type of typo is even mentioned in scripts/spelling.txt.
Regards
Jakub Raczynski
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH ipsec 2/3] tools/selftests: Add a VXLAN+IPsec traffic test
From: Cosmin Ratiu @ 2026-04-22 14:06 UTC (permalink / raw)
To: netdev
Cc: Steffen Klassert, Herbert Xu, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Andrew Lunn,
Shuah Khan, Cosmin Ratiu, Nimrod Oren, Carolina Jubran,
Gal Pressman, linux-kselftest
In-Reply-To: <20260422140648.3877129-1-cratiu@nvidia.com>
There are VXLAN tests and IPsec tests, but there is no test that
combines the two protocols and exercises the tunnel-over-ipsec code
paths. Fix that by adding a traffic test with VXLAN and IPsec using
crypto offload. This is runnable on HW which supports ESP offload (so no
nsim unfortunately).
Traffic is done with iperf3 and the test validates that there are no
packet drops and iperf3 can get to at least 100 Mbps (a very
conservative value on today's crypto offload HW, as it can typically
reach multi-Gbps rates).
Ran right now, the test fails due to a recently exposed bug in xfrm,
which will be fixed in the next patch:
# ./tools/testing/selftests/drivers/net/hw/ipsec_vxlan.py
TAP version 13
1..4
# Check| At ./tools/testing/selftests/drivers/net/hw/ipsec_vxlan.py,
# line 161, in test_vxlan_ipsec_crypto_offload:
# Check| ksft_eq(drops_after - drops_before, 0,
# Check failed 189 != 0 TX drops during VXLAN+IPsec
# Check| At ./tools/testing/selftests/drivers/net/hw/ipsec_vxlan.py,
# line 163, in test_vxlan_ipsec_crypto_offload:
# Check| ksft_ge(bw_gbps, 0.1,
# Check failed 0.0015058278404812596 < 0.1 Minimum 100Mbps over
# VXLAN+IPsec
not ok 1 ipsec_vxlan.test_vxlan_ipsec_crypto_offload.outer_v4_inner_v4
...
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
---
.../testing/selftests/drivers/net/hw/Makefile | 1 +
tools/testing/selftests/drivers/net/hw/config | 5 +
.../selftests/drivers/net/hw/ipsec_vxlan.py | 204 ++++++++++++++++++
3 files changed, 210 insertions(+)
create mode 100755 tools/testing/selftests/drivers/net/hw/ipsec_vxlan.py
diff --git a/tools/testing/selftests/drivers/net/hw/Makefile b/tools/testing/selftests/drivers/net/hw/Makefile
index 85ca4d1ecf9e..3b6ff4708005 100644
--- a/tools/testing/selftests/drivers/net/hw/Makefile
+++ b/tools/testing/selftests/drivers/net/hw/Makefile
@@ -30,6 +30,7 @@ TEST_PROGS = \
gro_hw.py \
hw_stats_l3.sh \
hw_stats_l3_gre.sh \
+ ipsec_vxlan.py \
iou-zcrx.py \
irq.py \
loopback.sh \
diff --git a/tools/testing/selftests/drivers/net/hw/config b/tools/testing/selftests/drivers/net/hw/config
index dd50cb8a7911..ae0168c2bbe6 100644
--- a/tools/testing/selftests/drivers/net/hw/config
+++ b/tools/testing/selftests/drivers/net/hw/config
@@ -12,5 +12,10 @@ CONFIG_NET_IPGRE=y
CONFIG_NET_IPGRE_DEMUX=y
CONFIG_NETKIT=y
CONFIG_NET_SCH_INGRESS=y
+CONFIG_INET6_ESP=y
+CONFIG_INET6_ESP_OFFLOAD=y
+CONFIG_INET_ESP=y
+CONFIG_INET_ESP_OFFLOAD=y
CONFIG_UDMABUF=y
CONFIG_VXLAN=y
+CONFIG_XFRM_USER=y
diff --git a/tools/testing/selftests/drivers/net/hw/ipsec_vxlan.py b/tools/testing/selftests/drivers/net/hw/ipsec_vxlan.py
new file mode 100755
index 000000000000..0740a4d85240
--- /dev/null
+++ b/tools/testing/selftests/drivers/net/hw/ipsec_vxlan.py
@@ -0,0 +1,204 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0
+"""Traffic test for VXLAN + IPsec crypto-offload."""
+
+import os
+
+from lib.py import ksft_run, ksft_exit, ksft_eq, ksft_ge
+from lib.py import ksft_variants, KsftNamedVariant, KsftSkipEx
+from lib.py import CmdExitFailure, NetDrvEpEnv, cmd, defer, ethtool, ip
+from lib.py import Iperf3Runner
+
+# Inner tunnel addresses - TEST-NET-2 (RFC 5737) / doc prefix (RFC 3849)
+INNER_V4_LOCAL = "198.51.100.1"
+INNER_V4_REMOTE = "198.51.100.2"
+INNER_V6_LOCAL = "2001:db8:100::1"
+INNER_V6_REMOTE = "2001:db8:100::2"
+
+# ESP parameters
+SPI_OUT = "0x1000"
+SPI_IN = "0x1001"
+# 128-bit key + 32-bit salt = 20 bytes hex, 128-bit ICV
+ESP_AEAD = "aead 'rfc4106(gcm(aes))' 0x" + "01" * 20 + " 128"
+
+
+def xfrm(args, host=None):
+ """Runs 'ip xfrm' via shell to preserve parentheses in algo names."""
+ cmd(f"ip xfrm {args}", shell=True, host=host)
+
+
+def check_xfrm_offload_support():
+ """Skips if iproute2 lacks xfrm offload support."""
+ out = cmd("ip xfrm state help", fail=False)
+ if "offload" not in out.stdout + out.stderr:
+ raise KsftSkipEx("iproute2 too old, missing xfrm offload")
+
+
+def check_esp_hw_offload(cfg):
+ """Skips if device lacks esp-hw-offload support."""
+ check_xfrm_offload_support()
+ try:
+ feat = ethtool(f"-k {cfg.ifname}", json=True)[0]
+ except (CmdExitFailure, IndexError) as e:
+ raise KsftSkipEx(f"can't query features: {e}") from e
+ if not feat.get("esp-hw-offload", {}).get("active"):
+ raise KsftSkipEx("Device does not support esp-hw-offload")
+
+
+def get_tx_drops(cfg):
+ """Returns TX dropped counter from the physical device."""
+ stats = ip("-s -s link show dev " + cfg.ifname, json=True)[0]
+ return stats["stats64"]["tx"]["dropped"]
+
+
+def setup_vxlan_ipsec(cfg, outer_ipver, inner_ipver):
+ """Sets up VXLAN tunnel with IPsec transport-mode crypto-offload."""
+ vxlan_name = f"vx{os.getpid()}"
+ local_addr = cfg.addr_v[outer_ipver]
+ remote_addr = cfg.remote_addr_v[outer_ipver]
+
+ if inner_ipver == "4":
+ inner_local = f"{INNER_V4_LOCAL}/24"
+ inner_remote = f"{INNER_V4_REMOTE}/24"
+ addr_extra = ""
+ else:
+ inner_local = f"{INNER_V6_LOCAL}/64"
+ inner_remote = f"{INNER_V6_REMOTE}/64"
+ addr_extra = " nodad"
+
+ if outer_ipver == "6":
+ vxlan_opts = "udp6zerocsumtx udp6zerocsumrx"
+ else:
+ vxlan_opts = "noudpcsum"
+
+ # VXLAN tunnel - local side
+ ip(f"link add {vxlan_name} type vxlan id 100 dstport 4789 {vxlan_opts} "
+ f"local {local_addr} remote {remote_addr} dev {cfg.ifname}")
+ defer(ip, f"link del {vxlan_name}")
+ ip(f"addr add {inner_local} dev {vxlan_name}{addr_extra}")
+ ip(f"link set {vxlan_name} up")
+
+ # VXLAN tunnel - remote side
+ ip(f"link add {vxlan_name} type vxlan id 100 dstport 4789 {vxlan_opts} "
+ f"local {remote_addr} remote {local_addr} dev {cfg.remote_ifname}",
+ host=cfg.remote)
+ defer(ip, f"link del {vxlan_name}", host=cfg.remote)
+ ip(f"addr add {inner_remote} dev {vxlan_name}{addr_extra}",
+ host=cfg.remote)
+ ip(f"link set {vxlan_name} up", host=cfg.remote)
+
+ # xfrm state - local outbound SA
+ xfrm(f"state add src {local_addr} dst {remote_addr} "
+ f"proto esp spi {SPI_OUT} "
+ f"{ESP_AEAD} "
+ f"mode transport offload crypto dev {cfg.ifname} dir out")
+ defer(xfrm, f"state del src {local_addr} dst {remote_addr} "
+ f"proto esp spi {SPI_OUT}")
+
+ # xfrm state - local inbound SA
+ xfrm(f"state add src {remote_addr} dst {local_addr} "
+ f"proto esp spi {SPI_IN} "
+ f"{ESP_AEAD} "
+ f"mode transport offload crypto dev {cfg.ifname} dir in")
+ defer(xfrm, f"state del src {remote_addr} dst {local_addr} "
+ f"proto esp spi {SPI_IN}")
+
+ # xfrm state - remote outbound SA (mirror, software crypto)
+ xfrm(f"state add src {remote_addr} dst {local_addr} "
+ f"proto esp spi {SPI_IN} "
+ f"{ESP_AEAD} "
+ f"mode transport",
+ host=cfg.remote)
+ defer(xfrm, f"state del src {remote_addr} dst {local_addr} "
+ f"proto esp spi {SPI_IN}", host=cfg.remote)
+
+ # xfrm state - remote inbound SA (mirror, software crypto)
+ xfrm(f"state add src {local_addr} dst {remote_addr} "
+ f"proto esp spi {SPI_OUT} "
+ f"{ESP_AEAD} "
+ f"mode transport",
+ host=cfg.remote)
+ defer(xfrm, f"state del src {local_addr} dst {remote_addr} "
+ f"proto esp spi {SPI_OUT}", host=cfg.remote)
+
+ # xfrm policy - local out
+ xfrm(f"policy add src {local_addr} dst {remote_addr} "
+ f"proto udp dport 4789 dir out "
+ f"tmpl src {local_addr} dst {remote_addr} proto esp mode transport")
+ defer(xfrm, f"policy del src {local_addr} dst {remote_addr} "
+ f"proto udp dport 4789 dir out")
+
+ # xfrm policy - local in
+ xfrm(f"policy add src {remote_addr} dst {local_addr} "
+ f"proto udp dport 4789 dir in "
+ f"tmpl src {remote_addr} dst {local_addr} proto esp mode transport")
+ defer(xfrm, f"policy del src {remote_addr} dst {local_addr} "
+ f"proto udp dport 4789 dir in")
+
+ # xfrm policy - remote out
+ xfrm(f"policy add src {remote_addr} dst {local_addr} "
+ f"proto udp dport 4789 dir out "
+ f"tmpl src {remote_addr} dst {local_addr} proto esp mode transport",
+ host=cfg.remote)
+ defer(xfrm, f"policy del src {remote_addr} dst {local_addr} "
+ f"proto udp dport 4789 dir out", host=cfg.remote)
+
+ # xfrm policy - remote in
+ xfrm(f"policy add src {local_addr} dst {remote_addr} "
+ f"proto udp dport 4789 dir in "
+ f"tmpl src {local_addr} dst {remote_addr} proto esp mode transport",
+ host=cfg.remote)
+ defer(xfrm, f"policy del src {local_addr} dst {remote_addr} "
+ f"proto udp dport 4789 dir in", host=cfg.remote)
+
+
+def _vxlan_ipsec_variants():
+ """Generates outer/inner IP version variants."""
+ for outer in ["4", "6"]:
+ for inner in ["4", "6"]:
+ yield KsftNamedVariant(f"outer_v{outer}_inner_v{inner}", outer, inner)
+
+
+@ksft_variants(_vxlan_ipsec_variants())
+def test_vxlan_ipsec_crypto_offload(cfg, outer_ipver, inner_ipver):
+ """Tests VXLAN+IPsec crypto-offload has no TX drops."""
+ cfg.require_ipver(outer_ipver)
+ check_esp_hw_offload(cfg)
+
+ setup_vxlan_ipsec(cfg, outer_ipver, inner_ipver)
+
+ if inner_ipver == "4":
+ inner_local = INNER_V4_LOCAL
+ inner_remote = INNER_V4_REMOTE
+ ping = "ping"
+ else:
+ inner_local = INNER_V6_LOCAL
+ inner_remote = INNER_V6_REMOTE
+ ping = "ping -6"
+
+ cmd(f"{ping} -c 1 -W 2 {inner_remote}")
+
+ drops_before = get_tx_drops(cfg)
+
+ runner = Iperf3Runner(cfg, server_ip=inner_local,
+ client_ip=inner_remote)
+ bw_gbps = runner.measure_bandwidth(reverse=True)
+
+ cfg.wait_hw_stats_settle()
+ drops_after = get_tx_drops(cfg)
+
+ ksft_eq(drops_after - drops_before, 0,
+ comment="TX drops during VXLAN+IPsec")
+ ksft_ge(bw_gbps, 0.1,
+ comment="Minimum 100Mbps over VXLAN+IPsec")
+
+
+def main():
+ """Runs VXLAN+IPsec crypto-offload GSO selftest."""
+ with NetDrvEpEnv(__file__, nsim_test=False) as cfg:
+ ksft_run([test_vxlan_ipsec_crypto_offload], args=(cfg,))
+ ksft_exit()
+
+
+if __name__ == "__main__":
+ main()
--
2.53.0
^ permalink raw reply related
* [PATCH ipsec 1/3] tools/selftests: Use a sensible timeout value for iperf3 client
From: Cosmin Ratiu @ 2026-04-22 14:06 UTC (permalink / raw)
To: netdev
Cc: Steffen Klassert, Herbert Xu, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Andrew Lunn,
Shuah Khan, Cosmin Ratiu, Nimrod Oren, Carolina Jubran,
Gal Pressman, linux-kselftest
In-Reply-To: <20260422140648.3877129-1-cratiu@nvidia.com>
The default timeout of cmd() is 5 seconds and Iperf3Runner requests the
iperf3 client to run for 10 seconds, which clearly doesn't work since
commit [1] enforced the timeout parameter.
Use a value derived from duration as timeout (+5 seconds for
startup/teardown/various other overhead).
[1] commit f0bd19316663 ("selftests: net: fix timeout passed as positional argument to communicate()")
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
---
tools/testing/selftests/drivers/net/lib/py/load.py | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/drivers/net/lib/py/load.py b/tools/testing/selftests/drivers/net/lib/py/load.py
index f181fa2d38fc..e24660e5c27f 100644
--- a/tools/testing/selftests/drivers/net/lib/py/load.py
+++ b/tools/testing/selftests/drivers/net/lib/py/load.py
@@ -48,7 +48,10 @@ class Iperf3Runner:
Starts the iperf3 client with the configured options.
"""
cmdline = self._build_client(streams, duration, reverse)
- return cmd(cmdline, background=background, host=self.env.remote)
+ kwargs = {"background": background, "host": self.env.remote}
+ if not background:
+ kwargs["timeout"] = duration + 5
+ return cmd(cmdline, **kwargs)
def measure_bandwidth(self, reverse=False):
"""
--
2.53.0
^ permalink raw reply related
* [PATCH ipsec 3/3] xfrm: Don't clobber inner headers when already set
From: Cosmin Ratiu @ 2026-04-22 14:06 UTC (permalink / raw)
To: netdev
Cc: Steffen Klassert, Herbert Xu, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Andrew Lunn,
Shuah Khan, Cosmin Ratiu, Nimrod Oren, Carolina Jubran,
Gal Pressman, linux-kselftest
In-Reply-To: <20260422140648.3877129-1-cratiu@nvidia.com>
On VXLAN over IPsec egress, xfrm{4,6}_transport_output() blindly
overwrite inner_transport_header (== the inner TCP header saved in VXLAN
iptunnel_handle_offloads() -> skb_reset_inner_headers()) with the
current transport_header (== the VXLAN outer UDP header set by
udp_tunnel_xmit_skb()).
This was a latent bug, harmless until commit [1] added a doff validation
check in qdisc_pkt_len_segs_init() for encapsulated GSO packets. With
the wrong inner_transport_header set by xfrm, qdisc_pkt_len_segs_init()
interprets inner_transport_header as a TCP header, reads doff=0 from the
upper byte of the VNI and drops the packet with DROP_REASON_SKB_BAD_GSO.
Besides the use in GSO to determine the header size of segmented
packets, inner_transport_header might be used by drivers to set up
inner checksum offloading by pointing the HW to the inner transport
header. A quick browse through available drivers shows that mlx5 uses
skb->csum_start specifically for this scenario, while others either
don't support VXLAN over IPsec crypto offload (ixgbe) or the HW is
capable of parsing the packets itself (nfp, Chelsio).
But in all cases, it is more correct to let the inner_transport_header
point to the innermost header instead of overwriting it in xfrm.
So fix this by guarding all four inner header save sites in
xfrm_output.c (xfrm{4,6}_transport_output, xfrm{4,6}_tunnel_encap_add)
with a check for skb->inner_protocol. When inner_protocol is set, a
tunnel layer (VXLAN, Geneve, GRE, etc.) has already saved the correct
inner header offsets and they must not be overwritten. When
inner_protocol is zero, no prior tunnel encapsulation exists and xfrm
must save the inner headers itself. The tunnel mode checks are only
added for completion, since they aren't strictly required, as
xfrm_output() forces software GSO in tunnel mode before encap.
This makes the previously added test pass:
# ./tools/testing/selftests/drivers/net/hw/ipsec_vxlan.py
TAP version 13
1..4
ok 1 ipsec_vxlan.test_vxlan_ipsec_crypto_offload.outer_v4_inner_v4
ok 2 ipsec_vxlan.test_vxlan_ipsec_crypto_offload.outer_v4_inner_v6
ok 3 ipsec_vxlan.test_vxlan_ipsec_crypto_offload.outer_v6_inner_v4
ok 4 ipsec_vxlan.test_vxlan_ipsec_crypto_offload.outer_v6_inner_v6
# Totals: pass:4 fail:0 xfail:0 xpass:0 skip:0 error:0
[1] commit 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()")
Fixes: f1bd7d659ef0 ("xfrm: Add encapsulation header offsets while SKB is not encrypted")
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
---
net/xfrm/xfrm_output.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index a9652b422f51..cc35c2fcbbe0 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -66,7 +66,9 @@ static int xfrm4_transport_output(struct xfrm_state *x, struct sk_buff *skb)
struct iphdr *iph = ip_hdr(skb);
int ihl = iph->ihl * 4;
- skb_set_inner_transport_header(skb, skb_transport_offset(skb));
+ if (!skb->inner_protocol)
+ skb_set_inner_transport_header(skb,
+ skb_transport_offset(skb));
skb_set_network_header(skb, -x->props.header_len);
skb->mac_header = skb->network_header +
@@ -167,7 +169,9 @@ static int xfrm6_transport_output(struct xfrm_state *x, struct sk_buff *skb)
int hdr_len;
iph = ipv6_hdr(skb);
- skb_set_inner_transport_header(skb, skb_transport_offset(skb));
+ if (!skb->inner_protocol)
+ skb_set_inner_transport_header(skb,
+ skb_transport_offset(skb));
hdr_len = xfrm6_hdr_offset(x, skb, &prevhdr);
if (hdr_len < 0)
@@ -276,8 +280,10 @@ static int xfrm4_tunnel_encap_add(struct xfrm_state *x, struct sk_buff *skb)
struct iphdr *top_iph;
int flags;
- skb_set_inner_network_header(skb, skb_network_offset(skb));
- skb_set_inner_transport_header(skb, skb_transport_offset(skb));
+ if (!skb->inner_protocol) {
+ skb_set_inner_network_header(skb, skb_network_offset(skb));
+ skb_set_inner_transport_header(skb, skb_transport_offset(skb));
+ }
skb_set_network_header(skb, -x->props.header_len);
skb->mac_header = skb->network_header +
@@ -321,8 +327,10 @@ static int xfrm6_tunnel_encap_add(struct xfrm_state *x, struct sk_buff *skb)
struct ipv6hdr *top_iph;
int dsfield;
- skb_set_inner_network_header(skb, skb_network_offset(skb));
- skb_set_inner_transport_header(skb, skb_transport_offset(skb));
+ if (!skb->inner_protocol) {
+ skb_set_inner_network_header(skb, skb_network_offset(skb));
+ skb_set_inner_transport_header(skb, skb_transport_offset(skb));
+ }
skb_set_network_header(skb, -x->props.header_len);
skb->mac_header = skb->network_header +
--
2.53.0
^ permalink raw reply related
* [PATCH net v2] net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()
From: Morduan Zang @ 2026-04-22 14:07 UTC (permalink / raw)
To: michal.pecio
Cc: andrew+netdev, davem, edumazet, kuba, linux-kernel, linux-usb,
netdev, pabeni, petkan, syzbot+3f46c095ac0ca048cb71,
syzkaller-bugs, zhangdandan, zhanjun, Andrew Lunn
In-Reply-To: <20260421220547.2f7f9d85.michal.pecio@gmail.com>
From: Zhan Jun <zhanjun@uniontech.com>
syzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit()
when accessing skb->len for tx statistics after usb_submit_urb() has
been called:
BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760
drivers/net/usb/rtl8150.c:712
Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226
The URB completion handler write_bulk_callback() frees the skb via
dev_kfree_skb_irq(dev->tx_skb). The URB may complete on another CPU
in softirq context before usb_submit_urb() returns in the submitter,
so by the time the submitter reads skb->len the skb has already been
queued to the per-CPU completion_queue and freed by net_tx_action():
CPU A (xmit) CPU B (USB completion softirq)
------------ ------------------------------
dev->tx_skb = skb;
usb_submit_urb() --+
|-------> write_bulk_callback()
| dev_kfree_skb_irq(dev->tx_skb)
| net_tx_action()
| napi_skb_cache_put() <-- free
netdev->stats.tx_bytes |
+= skb->len; <-- UAF read
Fix it by caching skb->len before submitting the URB and using the
cached value when updating the tx_bytes counter.
The pre-existing tx_bytes semantics are preserved: the counter tracks
the original frame length (skb->len), not the ETH_ZLEN/USB-alignment
padded "count" value that is handed to the device. Changing that
would be a user-visible accounting change and is out of scope for
this UAF fix.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+3f46c095ac0ca048cb71@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/69e69ee7.050a0220.24bfd3.002b.GAE@google.com/
Closes: https://syzkaller.appspot.com/bug?extid=3f46c095ac0ca048cb71
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Zhan Jun <zhanjun@uniontech.com>
---
Changes in v2:
- Drop the vague "This mirrors the fix pattern used by other USB
network drivers." claim from the changelog (Michal Pecio).
- Clarify that the patch intentionally preserves the existing
tx_bytes semantics (no ETH_ZLEN/USB padding accounted), and that
adjusting that is out of scope for this UAF fix (Michal Pecio).
- Use the correct "[PATCH net]" subject prefix per
Documentation/process/maintainer-netdev.rst (Andrew Lunn).
- Add Reviewed-by: Andrew Lunn.
- No functional changes; code diff is identical to v1.
v1: https://lore.kernel.org/all/73ACB7391A6DE033+20260421110412.14795-1-zhangdandan@uniontech.com/
---
drivers/net/usb/rtl8150.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index 4cda0643afb6..6fc6be0cced6 100644
--- a/drivers/net/usb/rtl8150.c
+++ b/drivers/net/usb/rtl8150.c
@@ -683,6 +683,7 @@ static netdev_tx_t rtl8150_start_xmit(struct sk_buff *skb,
struct net_device *netdev)
{
rtl8150_t *dev = netdev_priv(netdev);
+ unsigned int skb_len;
int count, res;
/* pad the frame and ensure terminating USB packet, datasheet 9.2.3 */
@@ -694,6 +695,14 @@ static netdev_tx_t rtl8150_start_xmit(struct sk_buff *skb,
return NETDEV_TX_OK;
}
+ /*
+ * Cache skb->len before submitting the URB: the URB completion
+ * handler (write_bulk_callback) frees the skb, and it may run
+ * on another CPU before usb_submit_urb() returns, which would
+ * leave skb dangling here.
+ */
+ skb_len = skb->len;
+
netif_stop_queue(netdev);
dev->tx_skb = skb;
usb_fill_bulk_urb(dev->tx_urb, dev->udev, usb_sndbulkpipe(dev->udev, 2),
@@ -709,7 +718,7 @@ static netdev_tx_t rtl8150_start_xmit(struct sk_buff *skb,
}
} else {
netdev->stats.tx_packets++;
- netdev->stats.tx_bytes += skb->len;
+ netdev->stats.tx_bytes += skb_len;
netif_trans_update(netdev);
}
--
2.51.0
^ permalink raw reply related
* [PATCH ipsec 0/3] xfrm: Don't clobber inner headers when already set
From: Cosmin Ratiu @ 2026-04-22 14:06 UTC (permalink / raw)
To: netdev
Cc: Steffen Klassert, Herbert Xu, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Andrew Lunn,
Shuah Khan, Cosmin Ratiu, Nimrod Oren, Carolina Jubran,
Gal Pressman, linux-kselftest
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
net/xfrm/xfrm_output.c | 20 +-
.../testing/selftests/drivers/net/hw/Makefile | 1 +
tools/testing/selftests/drivers/net/hw/config | 5 +
.../selftests/drivers/net/hw/ipsec_vxlan.py | 204 ++++++++++++++++++
.../selftests/drivers/net/lib/py/load.py | 5 +-
5 files changed, 228 insertions(+), 7 deletions(-)
create mode 100755 tools/testing/selftests/drivers/net/hw/ipsec_vxlan.py
--
2.53.0
^ permalink raw reply
* Re: [PATCH net-next v2 13/14] net: macb: use context swapping in .set_ringparam()
From: Théo Lebrun @ 2026-04-22 14:00 UTC (permalink / raw)
To: Jakub Kicinski, Alexandre Belloni
Cc: nicolas.ferre, claudiu.beznea, andrew+netdev, davem, edumazet,
pabeni, richardcochran, linux, pvalerio, conor, nb,
vladimir.kondratiev, gregory.clement, benoit.monin, tawfik.bayouk,
thomas.petazzoni, maxime.chevallier, netdev, linux-kernel
In-Reply-To: <20260414005654.3766959-1-kuba@kernel.org>
On Tue Apr 14, 2026 at 2:56 AM CEST, 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: macb: use context swapping in .set_ringparam()
>
> This patch modifies the ethtool set_ringparam implementation to use a
> context swapping mechanism. Instead of closing and reopening the interface,
> it allocates new buffers, stops the interface temporarily, swaps the active
> context, and then frees the old one.
>
>> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
>> index 3deab87c565b5..d1536cb1e40bb 100644
>> --- a/drivers/net/ethernet/cadence/macb_main.c
>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>> @@ -3081,6 +3081,89 @@ static void macb_configure_dma(struct macb *bp)
> [ ... ]
>> +static void macb_context_swap_start(struct macb *bp)
>> +{
> [ ... ]
>> + for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
>> + napi_disable(&queue->napi_rx);
>> + napi_disable(&queue->napi_tx);
>
> This isn't a regression from this patch, but does calling napi_disable()
> unconditionally crash on EMAC devices?
>
> EMAC devices appear to not initialize NAPI, which leaves the NAPI struct
> zero-initialized (n->dev is NULL), potentially causing a NULL pointer
> dereference in napi_disable(). Additionally, does this path also blindly
> call bp->macbgem_ops.mog_init_rings() which is NULL on EMAC?
So the LLM is correct in that queue->napi_{rx,tx} fields are never
initialised on at91 platforms [0]. Then we use the fields from many
places without checking.
Most are safe because at91 uses its own netdev_ops.
Functions that get called on at91 and do NAPI calls are:
- macb_suspend() & macb_resume() => system-wide suspend => ignored
- macb_{close,open}() called by macb_set_ringparam()
The codepaths for at91 are so different, context swap support for at91
sounds unrelevant. I'll update both change_mtu and set_ringparam to
return -EOPNOTSUPP if netif_running() && IS_EMAC.
[0]: NAPI fields are initialised in macb_init_dflt() which is either
used as the default config->init() or called by some of those init
functions. at91ether_init() doesn't.
>
>> + netdev_tx_reset_queue(netdev_get_tx_queue(bp->netdev, q));
>> + cancel_work_sync(&queue->tx_error_task);
>> + }
> [ ... ]
>> +static void macb_context_swap_end(struct macb *bp,
>> + struct macb_context *new_ctx)
>> +{
> [ ... ]
>> + /* Swap contexts & give buffer pointers to HW. */
>> +
>> + old_ctx = bp->ctx;
>> + bp->ctx = new_ctx;
>> + macb_init_buffers(bp);
>
> Since the new context swap doesn't call phylink_stop(), could a concurrent
> macb_mac_link_up() execution set the RE and TE bits in NCR during the window
> where bp->lock is dropped?
>
> If so, macb_init_buffers() would write new DMA ring base addresses to RBQP
> and TBQP while the MAC is actively enabled, which violates hardware
> specifications and could cause DMA corruption.
Again this is correct. We can have a race inbetween the swap and phylink
callbacks. However running phylink_stop() would partially ruin the idea
behind context swapping.
bp->lock is not the solution. We need either to disable phylink
operations for the swap duration or to synchronise with them. We cannot
grab bp->lock for the whole swap timespan because some calls might want
to sleep.
Both .mac_link_{up,down}() get called by phylink_resolve() which
acquires phydev->mutex [1]. Getting this mutex for the swap operation
sounds like the solution. PHY status updates will be delayed until the
end of our context swap operation (or the opposite).
Accessible from bp->netdev->phydev->lock. A few drivers already grab
that lock, but no one is for context swapping. Looked at fbnic for
example and there is no sync inbetween phylink ops and set_ringparam.
See fbnic_set_ringparam(), fbnic_phylink_mac_link_down
(), fbnic_mac_link_down_asic(). Maybe the sequence has been crafted to
work fine with concurrent accesses?
⟩ git grep -l 'mutex_lock.*phydev' drivers/net/ethernet/
drivers/net/ethernet/broadcom/genet/bcmgenet_wol.c
drivers/net/ethernet/broadcom/genet/bcmmii.c
drivers/net/ethernet/cadence/macb_main.c
drivers/net/ethernet/faraday/ftgmac100.c
drivers/net/ethernet/realtek/r8169_main.c
drivers/net/ethernet/ti/icssg/icssg_prueth.c
[1]: https://elixir.bootlin.com/linux/v7.0/source/drivers/net/phy/phylink.c#L1620
>> + if (!(bp->caps & MACB_CAPS_MACB_IS_EMAC)) {
>> + for (q = 0, queue = bp->queues; q < bp->num_queues;
>> + ++q, ++queue) {
>> + queue_writel(queue, IER,
>> + bp->rx_intr_mask |
>> + MACB_TX_INT_FLAGS |
>> + MACB_BIT(HRESP));
>> + }
>> + }
>
> Hardware interrupts are disabled unconditionally for all devices in
> macb_context_swap_start() by writing -1 to IDR.
>
> Will this explicit check prevent EMAC devices from having their interrupts
> re-enabled?
>
> Since EMAC devices do not use NAPI and rely on hardware interrupts, leaving
> them masked might silently halt all network traffic after a ring parameter
> change.
The check will be dropped. As said above, context swapping won't support
at91 platforms.
>> + ctrl = macb_readl(bp, NCR);
>> + macb_writel(bp, NCR, ctrl | MACB_BIT(RE) | MACB_BIT(TE));
>
> Can this unprotected read-modify-write of the NCR register race with phylink
> state changes?
>
> If an asynchronous phylink callback like macb_mac_config() modifies NCR
> while holding bp->lock, this unlocked write could overwrite and drop those
> concurrent updates.
The phydev->lock will help here as well.
macb_mac_config() == phylink_mac_ops::mac_config()
<- phylink_mac_config()
<- phylink_major_config()
<- phylink_resolve() (OR phylink_mac_initial_config())
both grab phydev->lock
>
>> +
>> + netif_tx_start_all_queues(bp->netdev);
>> +
>> + /* Free old context. */
>> +
>> + macb_free_consistent(old_ctx);
>
> This isn't a regression from this patch, but does this context swap leak
> pending TX packets and their DMA mappings?
>
> When freeing the old context, macb_free_consistent() appears to only free
> the pointer array. If it doesn't iterate from txq->tail to txq->head to
> unmap the active DMA mappings and free the sk_buff structs, repeatedly
> modifying ring parameters could cause a memory and DMA mapping leak.
Yes it does. I already have a patch pending. This bug has been present
since forever. :-)
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] mptcp: do not drop partial packets
From: Paolo Abeni @ 2026-04-22 13:51 UTC (permalink / raw)
To: Shardul Bankar, matttbe, martineau
Cc: geliang, davem, edumazet, kuba, horms, netdev, mptcp,
linux-kernel, janak, kalpan.jani, Shardul Bankar
In-Reply-To: <20260422120954.8877-1-shardul.b@mpiricsoftware.com>
On 4/22/26 2:09 PM, Shardul Bankar wrote:
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index 614c3f583ca0..6858e6e283e3 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -397,12 +397,27 @@ static bool __mptcp_move_skb(struct sock *sk, struct sk_buff *skb)
> return false;
> }
>
> - /* old data, keep it simple and drop the whole pkt, sender
> - * will retransmit as needed, if needed.
> + /* Completely old data? */
> + if (!after64(MPTCP_SKB_CB(skb)->end_seq, msk->ack_seq)) {
> + MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
> + mptcp_drop(sk, skb);
> + return false;
> + }
> +
> + /* Partial packet: map_seq < ack_seq < end_seq.
> + * Skip the already-acked bytes and enqueue the new data.
> */
> - MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
> - mptcp_drop(sk, skb);
> - return false;
> + copy_len = MPTCP_SKB_CB(skb)->end_seq - msk->ack_seq;
> + MPTCP_SKB_CB(skb)->offset += msk->ack_seq - MPTCP_SKB_CB(skb)->map_seq;
here MPTCP_SKB_CB(skb)->offset is always != 0 ...
> + msk->bytes_received += copy_len;
> + WRITE_ONCE(msk->ack_seq, msk->ack_seq + copy_len);
> + tail = skb_peek_tail(&sk->sk_receive_queue);
> + if (tail && mptcp_try_coalesce(sk, tail, skb))
... so mptcp_try_coalesce() will always fail.
/P
^ permalink raw reply
* Re: [PATCH RFC net-next v2 2/2] af_packet: Add port specific handling for HSR
From: Sebastian Andrzej Siewior @ 2026-04-22 13:27 UTC (permalink / raw)
To: 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: <willemdebruijn.kernel.270fa204f615f@gmail.com>
On 2026-04-21 03:41:52 [-0400], Willem de Bruijn wrote:
> Sebastian Andrzej Siewior wrote:
Hi Willem,
> > I understand your concern. I tried to make as self contained as
> > possible and little runtime overhead as possible.
> >
> > > One perhaps interesting Rx only option I had missed before is
> > > SOF_TIMESTAMPING_OPT_PKTINFO. Would that give you the original
> > > device ifindex today?
> >
> > The upper logic expects to poll() on the fd. If I need to filter the
> > device based on this then breaks the expectations.
> > I need also to receive packets without a timestamp so I don't think this
> > works.
>
> I don't follow this. My suggestion is to optionally receive this
> additional metadata along with the data. Not as a filter.
Yes. Just ignore that part.
> > cb[] is limited to one layer. I do have a skb_ext variant working but
> > this requires cmsg to set it. Do you think about generic skb_ext which
> > is set from af_packet? But I don't think it brings much value if I can't
> > filter on the RX side before returning the packet to userland.
> >
> > > 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)?
> >
> > So I have a skb->mark variant working. I do read on the ethX interface
>
> When reading on both ethX interfaces, that gives you all the info you
> need on Rx, right? Or alternatively by attaching to hsr0 with
> SOF_TIMESTAMPING_OPT_PKTINFO.
>
> So skb->mark is only relevant to the Tx side, right? There might be
> yet another way to identify in the hsr ndo_start_xmit that a packet
> arrived from a PF_PACKET socket. E.g., by checking skb->sk->sk_family.
> As alternative or complement to skb->protocol.
>
> Btw, on receive the inverse could also be true: insert a synthetic
> header and pop that in userspace, e.g., a VLAN tag.
So I made this:
I open hsr0 for TX with a custom header. The header is expected if the
ether-type is set to PTP. This extra header holds the HSR-header
information and port request.
I open eth0 for RX. I set PACKET_IGNORE_OUTGOING to avoid the feedback
from hsr0 writes. This is part is crucial ;)
I use skb_ext to pass the information from the inline-header to
the network driver since the data pointer of the skb is forwarded after
that header. In the end I have no idea if the network driver supports HW
offloading and needs this information or not and sends the packet as-is.
HW offloading becomes a bit tricky but relying on skb_ext (for HSR) and
checking otherwise for the ether type vs PTP (in the PRP case) does the
trick.
So it is slightly more complicated but seems to work.
Let me wait until after the merge window and then I present what I have.
Sebastian
^ permalink raw reply
* Re: [net-next v2 0/3] Add motorcomm 8531s set ds func and 8522 driver
From: Andrew Lunn @ 2026-04-22 13:27 UTC (permalink / raw)
To: Minda Chen
Cc: Frank, Andrew Lunn, Heiner Kallweit, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <20260422083255.29692-1-minda.chen@starfivetech.com>
On Wed, Apr 22, 2026 at 04:32:52PM +0800, Minda Chen wrote:
> This patch is for Starfive JHB100 EVB board. JHB100 contain
> 1 RGMII/RMII and 1 RMII synopsys GMAC cores. In the EVB board, RGMII
> interface connect with YT8531s Ethernet PHY. RMII interface connect
> with YT8522 ethernet PHY. So patch 1-2 is for RGMII interface
> patch 3 is RMII is for RMII interface.
>
> JHB100 is a Starfive new RISC-V SoC for datacenter BMC (BaseBoard
> Managent Controller). Similar with Aspeed 27x0.
>
> The JHB100 minimal system upstream is in progress:
> https://patchwork.kernel.org/project/linux-riscv/cover/20260403054945.467700-1-changhuang.liang@starfivetech.com/
Please take a read of sections 1.3 and 1.4 of:
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
Andrew
---
pw-bot: cr
^ permalink raw reply
* [PATCH] m68k: mvme147: Make me the maintainer
From: Daniel Palmer @ 2026-04-22 13:27 UTC (permalink / raw)
To: andrew+netdev
Cc: geert, James.Bottomley, martin.petersen, davem, edumazet, kuba,
pabeni, linux-m68k, linux-scsi, netdev, linux-kernel,
Daniel Palmer
I'm actively using mainline + patches on this board as a bootloader
for another VME board and as a terminal server using a multiport
serial board in the same VME backplane. I even have mainline u-boot
on real EPROMs.
Make me the maintainer of its ethernet, scsi and arch code so I get
an email before one or more of them get deleted.
Signed-off-by: Daniel Palmer <daniel@thingy.jp>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d25342ca8aa1..9949b5528bcf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15311,6 +15311,13 @@ S: Maintained
W: http://www.tazenda.demon.co.uk/phil/linux-hp
F: arch/m68k/hp300/
+M68K ON MVME147
+M: Daniel Palmer <daniel@thingy.jp>
+S: Maintained
+F: arch/m68k/mvme147/
+F: drivers/net/ethernet/amd/mvme147.c
+F: drivers/scsi/mvme147.*
+
M88DS3103 MEDIA DRIVER
L: linux-media@vger.kernel.org
S: Orphan
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2] net/intel: Replace manual array size calculation with ARRAY_SIZE
From: Dan Carpenter @ 2026-04-22 13:24 UTC (permalink / raw)
To: Jakub Raczynski
Cc: netdev, kuba, przemyslaw.kitszel, anthony.l.nguyen,
kernel-janitors
In-Reply-To: <20260422105710.268003-1-j.raczynski@samsung.com>
On Wed, Apr 22, 2026 at 12:57:12PM +0200, Jakub Raczynski wrote:
> There are still places in the code where manual calculation of array size
> exist, but it is good to enforce usage of single macro through the whole
> code as it makes code bit more readable.
> While at it, beautify condition surrounding it by reversing check and remove
> unnecessary casting.
>
> Signed-off-by: Jakub Raczynski <j.raczynski@samsung.com>
> ---
Thanks.
Reviewed-by: Dan Carpenter <error27@gmail.com>
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] net/intel: Replace manual array size calculation with ARRAY_SIZE
From: Dan Carpenter @ 2026-04-22 13:22 UTC (permalink / raw)
To: Jakub Raczynski
Cc: netdev, kuba, przemyslaw.kitszel, anthony.l.nguyen,
kernel-janitors
In-Reply-To: <aeiHkejLjhRKyj/u@AMDC4622.eu.corp.samsungelectronics.net>
On Wed, Apr 22, 2026 at 10:32:17AM +0200, Jakub Raczynski wrote:
> On Tue, Apr 21, 2026 at 05:11:19PM +0300, Dan Carpenter wrote:
> > On Tue, Apr 21, 2026 at 01:40:29PM +0200, Jakub Raczynski wrote:
> > >
> > > - if (!((u32)aq_rc < (sizeof(aq_to_posix) / sizeof((aq_to_posix)[0]))))
> > > + if (!((u32)aq_rc < ARRAY_SIZE(aq_to_posix)))
> >
> > This still isn't beautiful. There are so many parens. The !(foo < size)
> > formulation is weird. The cast is unnnecessary. Better to write it as:
> >
> > if (aq_rc >= ARRAY_SIZE(aq_to_posix))
> > return -ERANGE;
> >
> > > return -ERANGE;
> > >
> > > return aq_to_posix[aq_rc];
> >
> > regards,
> > dan carpenter
> >
>
> Alright, will beautify it and resend soon.
>
> I can see potential original intention of not comparing unsigned from sizeof
> with int, maybe that was original compiler configuration to include that
> warning.
Yeah. I know. I wrote a blog about this...
https://staticthinking.wordpress.com/2023/07/25/wsign-compare-is-garbage/
Check this out:
$ git grep '(int)' | grep ARRAY_SIZE | wc -l
53
It's as if we want array underflows.
> But at this variable range it is irrelevant and it is probably most disabled
> warning ever.
With the unnecessary cast I had to review to ensure that aq_rc is not
unsigned long type. There is a real downside to this kind of rule.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH net-deletions v2] net: remove unused ATM protocols and legacy ATM device drivers
From: Nikolay Aleksandrov @ 2026-04-22 13:17 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, skhan,
linux, tsbogend, maddy, mpe, npiggin, chleroy, 3chas3, idosch,
jani.nikula, mchehab+huawei, tytso, herbert, geert, ebiggers,
johannes.berg, jonathan.cameron, kees, kuniyu, fourier.thomas,
andriy.shevchenko, rdunlap, akpm, linux-doc, linux-mips,
linuxppc-dev, bridge, dwmw2
In-Reply-To: <20260422041846.2035118-1-kuba@kernel.org>
On 22/04/2026 07:18, Jakub Kicinski wrote:
> Remove the ATM protocol modules and PCI/SBUS ATM device drivers
> that are no longer in active use.
>
> The ATM core protocol stack, PPPoATM, BR2684, and USB DSL modem
> drivers (drivers/usb/atm/) are retained in-tree to maintain PPP
> over ATM (PPPoA) and PPPoE-over-BR2684 support for DSL connections.
>
> Removed ATM protocol modules:
> - net/atm/clip.c - Classical IP over ATM (RFC 2225)
> - net/atm/lec.c - LAN Emulation Client (LANE)
> - net/atm/mpc.c, mpoa_caches.c, mpoa_proc.c - Multi-Protocol Over ATM
>
> Removed PCI/SBUS ATM device drivers (drivers/atm/):
> - adummy, atmtcp - software/testing ATM devices
> - eni - Efficient Networks ENI155P (OC-3, ~1995)
> - fore200e - FORE Systems 200E PCI/SBUS (OC-3, ~1999)
> - he - ForeRunner HE (OC-3/OC-12, ~2000)
> - idt77105 - IDT 77105 25 Mbps ATM PHY
> - idt77252 - IDT 77252 NICStAR II (OC-3, ~2000)
> - iphase - Interphase ATM PCI (OC-3/DS3/E3)
> - lanai - Efficient Networks Speedstream 3010
> - nicstar - IDT 77201 NICStAR (155/25 Mbps, ~1999)
> - solos-pci - Traverse Technologies ADSL2+ PCI
> - suni - PMC S/UNI SONET PHY library
>
> Also clean up references in:
> - net/bridge/ - remove ATM LANE hook (br_fdb_test_addr_hook,
> br_fdb_test_addr)
> - net/core/dev.c - remove br_fdb_test_addr_hook export
> - defconfig files - remove ATM driver config options
>
> The removed code is moved to an out-of-tree module package (mod-orphan).
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> v2:
> - keep BR2684
> - correct the claim that Traverse Technologies is defunct,
> I'm still deleting the solos driver, chances are nobody uses it.
> Easy enough to revert back in since core is still around.
> The guiding principle is to keep USB modems and delete
> the rest as USB ADSL2+ CPEs were most popular historically.
> v1: https://lore.kernel.org/20260421021943.1295109-1-kuba@kernel.org
>
> CC: corbet@lwn.net
> CC: skhan@linuxfoundation.org
> CC: linux@armlinux.org.uk
> CC: tsbogend@alpha.franken.de
> CC: maddy@linux.ibm.com
> CC: mpe@ellerman.id.au
> CC: npiggin@gmail.com
> CC: chleroy@kernel.org
> CC: 3chas3@gmail.com
> CC: razor@blackwall.org
> CC: idosch@nvidia.com
> CC: jani.nikula@intel.com
> CC: mchehab+huawei@kernel.org
> CC: tytso@mit.edu
> CC: herbert@gondor.apana.org.au
> CC: geert@linux-m68k.org
> CC: ebiggers@kernel.org
> CC: johannes.berg@intel.com
> CC: jonathan.cameron@huawei.com
> CC: kees@kernel.org
> CC: kuniyu@google.com
> CC: fourier.thomas@gmail.com
> CC: andriy.shevchenko@intel.com
> CC: rdunlap@infradead.org
> CC: akpm@linux-foundation.org
> CC: linux-doc@vger.kernel.org
> CC: linux-mips@vger.kernel.org
> CC: linuxppc-dev@lists.ozlabs.org
> CC: bridge@lists.linux.dev
> CC: dwmw2@infradead.org
> CC: herbert@gondor.apana.org.au
> ---
> MAINTAINERS | 3 +-
> Documentation/.renames.txt | 2 -
> .../device_drivers/atm/fore200e.rst | 66 -
> .../networking/device_drivers/atm/index.rst | 2 -
> .../networking/device_drivers/atm/iphase.rst | 193 -
> drivers/atm/Kconfig | 325 --
> drivers/net/Kconfig | 2 -
> net/atm/Kconfig | 37 -
> drivers/Makefile | 1 -
> drivers/atm/Makefile | 32 -
> net/atm/Makefile | 4 -
> drivers/atm/eni.h | 136 -
> drivers/atm/fore200e.h | 973 -----
> drivers/atm/he.h | 845 ----
> drivers/atm/idt77105.h | 92 -
> drivers/atm/idt77252.h | 816 ----
> drivers/atm/idt77252_tables.h | 781 ----
> drivers/atm/iphase.h | 1452 -------
> drivers/atm/midway.h | 266 --
> drivers/atm/nicstar.h | 759 ----
> drivers/atm/suni.h | 242 --
> drivers/atm/tonga.h | 21 -
> drivers/atm/zeprom.h | 35 -
> net/atm/lec.h | 155 -
> net/atm/lec_arpc.h | 97 -
> net/atm/mpc.h | 65 -
> net/atm/mpoa_caches.h | 99 -
> net/bridge/br_private.h | 4 -
> drivers/atm/adummy.c | 202 -
> drivers/atm/atmtcp.c | 513 ---
> drivers/atm/eni.c | 2321 ----------
> drivers/atm/fore200e.c | 3012 -------------
> drivers/atm/he.c | 2861 -------------
> drivers/atm/idt77105.c | 376 --
> drivers/atm/idt77252.c | 3797 -----------------
> drivers/atm/iphase.c | 3283 --------------
> drivers/atm/lanai.c | 2603 -----------
> drivers/atm/nicstar.c | 2759 ------------
> drivers/atm/nicstarmac.c | 244 --
> drivers/atm/solos-attrlist.c | 83 -
> drivers/atm/solos-pci.c | 1496 -------
> drivers/atm/suni.c | 391 --
> net/atm/clip.c | 960 -----
> net/atm/lec.c | 2274 ----------
> net/atm/mpc.c | 1538 -------
> net/atm/mpoa_caches.c | 565 ---
> net/atm/mpoa_proc.c | 307 --
> net/bridge/br.c | 7 -
> net/bridge/br_fdb.c | 29 -
> net/core/dev.c | 7 -
> arch/arm/configs/ixp4xx_defconfig | 5 -
> arch/mips/configs/gpr_defconfig | 13 -
> arch/mips/configs/mtx1_defconfig | 13 -
> arch/powerpc/configs/ppc6xx_defconfig | 9 -
> drivers/atm/.gitignore | 5 -
> drivers/atm/nicstarmac.copyright | 61 -
> 56 files changed, 2 insertions(+), 37237 deletions(-)
> delete mode 100644 Documentation/networking/device_drivers/atm/fore200e.rst
> delete mode 100644 Documentation/networking/device_drivers/atm/iphase.rst
> delete mode 100644 drivers/atm/Kconfig
> delete mode 100644 drivers/atm/Makefile
> delete mode 100644 drivers/atm/eni.h
> delete mode 100644 drivers/atm/fore200e.h
> delete mode 100644 drivers/atm/he.h
> delete mode 100644 drivers/atm/idt77105.h
> delete mode 100644 drivers/atm/idt77252.h
> delete mode 100644 drivers/atm/idt77252_tables.h
> delete mode 100644 drivers/atm/iphase.h
> delete mode 100644 drivers/atm/midway.h
> delete mode 100644 drivers/atm/nicstar.h
> delete mode 100644 drivers/atm/suni.h
> delete mode 100644 drivers/atm/tonga.h
> delete mode 100644 drivers/atm/zeprom.h
> delete mode 100644 net/atm/lec.h
> delete mode 100644 net/atm/lec_arpc.h
> delete mode 100644 net/atm/mpc.h
> delete mode 100644 net/atm/mpoa_caches.h
> delete mode 100644 drivers/atm/adummy.c
> delete mode 100644 drivers/atm/atmtcp.c
> delete mode 100644 drivers/atm/eni.c
> delete mode 100644 drivers/atm/fore200e.c
> delete mode 100644 drivers/atm/he.c
> delete mode 100644 drivers/atm/idt77105.c
> delete mode 100644 drivers/atm/idt77252.c
> delete mode 100644 drivers/atm/iphase.c
> delete mode 100644 drivers/atm/lanai.c
> delete mode 100644 drivers/atm/nicstar.c
> delete mode 100644 drivers/atm/nicstarmac.c
> delete mode 100644 drivers/atm/solos-attrlist.c
> delete mode 100644 drivers/atm/solos-pci.c
> delete mode 100644 drivers/atm/suni.c
> delete mode 100644 net/atm/clip.c
> delete mode 100644 net/atm/lec.c
> delete mode 100644 net/atm/mpc.c
> delete mode 100644 net/atm/mpoa_caches.c
> delete mode 100644 net/atm/mpoa_proc.c
> delete mode 100644 drivers/atm/.gitignore
> delete mode 100644 drivers/atm/nicstarmac.copyright
>
FWIW,
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: Path forward for NFC in the kernel
From: David Heidelberg @ 2026-04-22 13:11 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Krzysztof Kozlowski, Michael Thalmeier, Raymond Hackley,
Michael Walle, Bongsu Jeon, Mark Greer, netdev, oe-linux-nfc
In-Reply-To: <20260421071044.67a3cee1@kernel.org>
On 21/04/2026 16:10, Jakub Kicinski wrote:
> On Fri, 17 Apr 2026 10:12:22 +0200 David Heidelberg wrote:
>>> +Cc David Heidelberg recently trying to use Linux NFC stack,
>>>
>>> Just "collecting" patches is not a big deal, I could do this, but
>>> actually reviewing the patches with necessary due diligence is the
>>> effort I could not provide in a reasonable time frame. And picking up
>>> patches without proper review feels risky...
>>
>> Hello Krzystof, Jakub,
>>
>> thanks for putting me into loop.
>>
>> I can do limited reviews and basic maintenance. My knowledge about NFC is for
>> now somehow limited (but I'm willing to invest my limited time into learning more).
>>
>> As "I & LLM" wrote [1] userspace very basic reader for GNOME and planning to do
>> more tight integration into GNOME, so would make sense to keep the kernel stack
>> alive.
>
> Hi David!
>
> Sorry for the delay, we (core maintainers) discussed the situation
> off-list and since our choices are either delete all this code or give
> you a chance, everyone agreed that the latter is strictly better :)
> It's a little unusual to designate someone who doesn't have a proven
> track record acting as a de facto maintainer, but such are the times...
>
> Our expectation would be that:
> - you'd create your own tree to gather NFC patches and send us
> periodic pull requests every 2 or 3 weeks, with what you gathered
> - act upon submissions within 48h of posting (excluding weekends)
>
> Of course we'll happy to provide any support and guidance you need,
> specially for the first few months.
>
> Is this what you had in mind? The phrase "limited reviews and basic
> maintenance" is slightly worrying, we assumed it's an expression of
> modesty rather than commitment? :)
Hi,
thanks for giving me the opportunity - I appreciate the trust, especially given
the circumstances.
Yes, this is broadly in line with what I had in mind. To clarify the “limited
reviews and basic maintenance” phrasing: that was more an attempt to set
expectations conservatively. I’m prepared to take on the responsibilities you
outlined — maintaining a tree, collecting and triaging patches, and sending
regular pull requests.
Regarding reviews and responsiveness: I can do the 48h turnaround for initial
feedback on submissions (excluding weekends, and occasional travel), and I’ll
make sure no patch sits unattended. For more complex changes where my current
NFC-specific knowledge may be a limiting factor, I’ll seek input rather than let
things stall.
I’m also planning to ramp up my familiarity with the NFC stack as I go, so I
expect both the quality and depth of my reviews to improve over time.
If that works for you, I’ll proceed with setting up a public tree and start
tracking incoming patches.
Thanks again for the support - I’ll likely take you up on that, especially early on.
Best regards,
David
^ permalink raw reply
* Re: [PATCH net 14/18] drivers: net: xircom: xirc2ps: Remove this driver
From: Andrew Lunn @ 2026-04-22 13:09 UTC (permalink / raw)
To: michael
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, linux-kernel, netdev,
linux-doc
In-Reply-To: <e36510873a1909a1bfd9a05cde99fef0@fritscher.net>
> thanks! If someone mentors me I could try... I have experience with C
> programming, esp. in the embedded world, but (almost) no experience with the
> Linux kernel development.
> But regression tests etc. can be conducted by me - on 32 and 64 bit
> machines. The oldest being a P120, the newest the mentioned X61 with its C2D
> CPU.
For a driver like this, regression testing is mostly what we need,
when we see patches for it.
Please take a look at the MAINTAINERs file, and see if you can send us
a patch adding yourself as the Maintainer of this driver.
Some documents to read:
https://docs.kernel.org/process/submitting-patches.html
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
For patches to MAINTAINERS, please base the patch on net.
Andrew
^ permalink raw reply
* Re: [PATCH net-deletions v2] net: remove unused ATM protocols and legacy ATM device drivers
From: David Woodhouse @ 2026-04-22 13:05 UTC (permalink / raw)
To: Jakub Kicinski, davem, openwrt-devel, Guy Ellis
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, skhan,
linux, tsbogend, maddy, mpe, npiggin, chleroy, 3chas3, razor,
idosch, jani.nikula, mchehab+huawei, tytso, herbert, geert,
ebiggers, johannes.berg, jonathan.cameron, kees, kuniyu,
fourier.thomas, andriy.shevchenko, rdunlap, akpm, linux-doc,
linux-mips, linuxppc-dev, bridge
In-Reply-To: <20260422041846.2035118-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 885 bytes --]
On Tue, 2026-04-21 at 21:18 -0700, Jakub Kicinski wrote:
>
> I'm still deleting the solos driver, chances are nobody uses it.
> Easy enough to revert back in since core is still around.
> The guiding principle is to keep USB modems and delete
> the rest as USB ADSL2+ CPEs were most popular historically.
Still not entirely convinced; I worked on both USB ATM modems and on
Solos, and the Solos is both the most modern and the only one I still
actually have. And the only one we have native support for that could
ever do full 24Mb/s ADSL2+, I believe.
If we drop it, OpenWrt will need to drop support for these, which I
think were quite popular at the time; there were a few UK resellers:
https://openwrt.org/toh/traverse/geos1_1
I still don't actually care *enough* to try to find an ADSL line I
could plug one into for testing though... :)
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] net: packetengines: remove obsolete yellowfin driver and vendor dir
From: Andrew Lunn @ 2026-04-22 13:04 UTC (permalink / raw)
To: Mingyu Wang
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, tglx, mingo, netdev,
linux-kernel
In-Reply-To: <20260422044820.485660-3-25181214217@stu.xidian.edu.cn>
On Wed, Apr 22, 2026 at 12:48:20PM +0800, Mingyu Wang wrote:
> Similar to the hamachi driver, the yellowfin driver supports hardware
> that is over two decades old and no longer in active use.
>
> Since yellowfin was the last remaining driver in the packetengines
> vendor directory, we can now safely remove the entire directory and
> drop its associated references from the parent Kconfig and Makefile.
>
> This eliminates dead code and reduces the overall maintenance burden
> on the netdev subsystem.
>
> Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 1/2] net: packetengines: remove obsolete hamachi driver
From: Andrew Lunn @ 2026-04-22 13:04 UTC (permalink / raw)
To: Mingyu Wang
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, tglx, mingo, netdev,
linux-kernel
In-Reply-To: <20260422044820.485660-2-25181214217@stu.xidian.edu.cn>
On Wed, Apr 22, 2026 at 12:48:19PM +0800, Mingyu Wang wrote:
> The PacketEngine Hamachi driver is for PCI hardware that has been
> obsolete for over two decades. It recently triggered arithmetic
> exceptions during automated fuzzing.
>
> As suggested by maintainers, remove the driver entirely to eliminate
> dead code and reduce the maintenance burden.
>
> Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] rxrpc: fix missing validation of ticket length in
From: Anderson Nascimento @ 2026-04-22 12:52 UTC (permalink / raw)
To: David Howells
Cc: Marc Dionne, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Steve Dickson, linux-afs, netdev,
linux-kernel
In-Reply-To: <2475724.1776861474@warthog.procyon.org.uk>
On Wed, Apr 22, 2026 at 9:38 AM David Howells <dhowells@redhat.com> wrote:
>
> > Subject: [PATCH] rxrpc: fix missing validation of ticket length in
>
> ...in rxrpc_preparse(), I presume?
>
In fact it was "non-XDR key preparsing", but "in rxrpc_preparse()" also works.
> David
>
--
Anderson Nascimento
Allele Security Intelligence
https://www.allelesecurity.com
^ permalink raw reply
* Re: [PATCH net 06/18] drivers: net: amd: Remove hplance and mvme147
From: Andrew Lunn @ 2026-04-22 12:50 UTC (permalink / raw)
To: Daniel Palmer
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan,
linux-kernel, netdev, linux-doc
In-Reply-To: <CAFr9PXk=3md2oVDqFbmQLNiVMkRr32pHMPNSeskdTpM-1huB=A@mail.gmail.com>
On Wed, Apr 22, 2026 at 06:38:28AM +0900, Daniel Palmer wrote:
> Hi Andrew,
>
> On Wed, 22 Apr 2026 at 04:39, Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > These drivers use the 7990 core with wrappers for the HP300 and
> > Motorola MVME147 SBC circa 1998. It is unlikely they are used with a
> > modern kernel.
>
> I have an MVME147 blinking away running mainline using the mvme147 driver.
> I think some of these need to be CC'd to the specific arch lists so
> the few people using them get a chance to pipe up.
That is part of the problem. No MAINTAINERs entry. so
./scripts/get_maintainers.py does not add an Cc: to the list.
> I think I'm the last person to have touched the mvme147, I don't mind
> being a maintainer for it.
Please submit an entry for MAINTAINERs.
I will drop this patch.
Andrew
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net 2/2] ice: ptp: use primary NAC semaphore on E825
From: Loktionov, Aleksandr @ 2026-04-22 12:48 UTC (permalink / raw)
To: Nitka, Grzegorz, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Kubalewski, Arkadiusz, Nguyen, Anthony L,
Kitszel, Przemyslaw
In-Reply-To: <20260422123144.485930-3-grzegorz.nitka@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Grzegorz Nitka
> Sent: Wednesday, April 22, 2026 2:32 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Kubalewski, Arkadiusz
> <arkadiusz.kubalewski@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-net 2/2] ice: ptp: use primary
> NAC semaphore on E825
>
> For E825 2xNAC configurations, PTP semaphore operations must hit the
> primary NAC register block so both sides coordinate on the same lock.
>
> Commit e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825
> devices") updated other primary-only PTP register accesses to use the
> primary NAC on non-primary functions, but left ice_ptp_lock() and
> ice_ptp_unlock() operating on the local NAC. As a result, secondary
> NAC PTP paths can take a different semaphore than the primary side.
>
> Select the primary hardware in ice_ptp_lock() and ice_ptp_unlock()
> when the current function is not primary, keeping semaphore operations
> symmetric and consistent with the rest of the 2xNAC PTP register
> access path.
>
> Fixes: e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825
> devices")
> Reviewed-by: Arkadiusz Kubalewski <Arkadiusz.kubalewski@intel.com>
> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
I recommend to add Cc: stable@vger.kernel.org
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> index 8bb94e785f2a..2c18e16fe053 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> @@ -5264,9 +5264,13 @@ static void ice_ptp_init_phy_e830(struct
> ice_ptp_hw *ptp)
> */
> bool ice_ptp_lock(struct ice_hw *hw)
> {
> + struct ice_pf *pf = container_of(hw, struct ice_pf, hw);
> u32 hw_lock;
> int i;
>
> + if (!ice_is_primary(hw))
> + hw = ice_get_primary_hw(pf);
> +
> #define MAX_TRIES 15
>
> for (i = 0; i < MAX_TRIES; i++) {
> @@ -5293,6 +5297,11 @@ bool ice_ptp_lock(struct ice_hw *hw)
> */
> void ice_ptp_unlock(struct ice_hw *hw)
> {
> + struct ice_pf *pf = container_of(hw, struct ice_pf, hw);
> +
> + if (!ice_is_primary(hw))
> + hw = ice_get_primary_hw(pf);
> +
> wr32(hw, PFTSYN_SEM + (PFTSYN_SEM_BYTES * hw->pf_id), 0); }
>
> --
> 2.39.3
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net 1/2] ice: ptp: serialize E825 PHY timer start with PTP lock
From: Loktionov, Aleksandr @ 2026-04-22 12:47 UTC (permalink / raw)
To: Nitka, Grzegorz, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Kubalewski, Arkadiusz, Nguyen, Anthony L,
Kitszel, Przemyslaw
In-Reply-To: <20260422123144.485930-2-grzegorz.nitka@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Grzegorz Nitka
> Sent: Wednesday, April 22, 2026 2:32 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Kubalewski, Arkadiusz
> <arkadiusz.kubalewski@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-net 1/2] ice: ptp: serialize
> E825 PHY timer start with PTP lock
>
> ice_start_phy_timer_eth56g() programs TIMETUS registers and issues
> INIT_INCVAL without holding the global PTP semaphore.
>
> This allows concurrent PTP command paths to interleave with PHY timer
> start, which can make the sequence fail and leave timer initialization
> inconsistent.
>
> Take the PTP lock around TIMETUS registers programming and INIT_INCVAL
> command execution, and make sure the lock is released on all error
> paths.
>
> Keep the subsequent sync step outside of this critical section, since
> ice_sync_phy_timer_eth56g() takes the same semaphore internally.
>
> Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C
> products")
> Reviewed-by: Arkadiusz Kubalewski <Arkadiusz.kubalewski@intel.com>
> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
I recommend to add Cc: stable@vger.kernel.org
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> index 672218e5d1f9..8bb94e785f2a 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> @@ -2141,16 +2141,23 @@ int ice_start_phy_timer_eth56g(struct ice_hw
> *hw, u8 port)
> }
> incval = (u64)hi << 32 | lo;
>
> + if (!ice_ptp_lock(hw)) {
> + dev_err(ice_hw_to_dev(hw), "Failed to acquire PTP
> semaphore\n");
> + return -EBUSY;
> + }
> +
> err = ice_write_40b_ptp_reg_eth56g(hw, port, PHY_REG_TIMETUS_L,
> incval);
> if (err)
> - return err;
> + goto err_ptp_unlock;
>
> err = ice_ptp_one_port_cmd(hw, port, ICE_PTP_INIT_INCVAL);
> if (err)
> - return err;
> + goto err_ptp_unlock;
>
> ice_ptp_exec_tmr_cmd(hw);
>
> + ice_ptp_unlock(hw);
> +
> err = ice_sync_phy_timer_eth56g(hw, port);
> if (err)
> return err;
> @@ -2166,6 +2173,10 @@ int ice_start_phy_timer_eth56g(struct ice_hw
> *hw, u8 port)
> ice_debug(hw, ICE_DBG_PTP, "Enabled clock on PHY port %u\n",
> port);
>
> return 0;
> +
> +err_ptp_unlock:
> + ice_ptp_unlock(hw);
> + return err;
> }
>
> /**
> --
> 2.39.3
^ permalink raw reply
* Re: [PATCH] net/stmmac: Fix typos: 'tx_undeflow_irq' -> 'tx_underflow_irq'
From: Andrew Lunn @ 2026-04-22 12:47 UTC (permalink / raw)
To: Jakub Raczynski
Cc: netdev, linux-kernel, kuba, davem, andrew+netdev, kernel-janitors,
linux-arm-kernel, linux-stm32
In-Reply-To: <aeiJ3zr4WJAm1UCk@AMDC4622.eu.corp.samsungelectronics.net>
> I don't see anything wrong with it?
> - naming is correct, same as stmmac_extra_stats from common.h, as it
> wouldn't compile otherwise
> - string length is ok, as max name length is ETH_GSTRING_LEN=32 and it is
> not close
> - ethtool just polls data from driver and in my tests it is ok
> - all instances of 'undeflow' are changed
> - 'underflow' semantic is ok, 'undeflow' is just not correct
>
> Please correct me if I am wrong, but imo no issues with this patch.
ABI
This name is published as part of the kAPI. You are changing its
name. User space could be looking for this name, even thought it has a
typo in it.
Andrew
^ permalink raw reply
* Re: [PATCH net 14/18] drivers: net: xircom: xirc2ps: Remove this driver
From: michael @ 2026-04-22 12:46 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, linux-kernel, netdev,
linux-doc
In-Reply-To: <408d1987-6ecb-4d3b-afed-8e202c8ff21d@lunn.ch>
Am 2026-04-22 14:15, schrieb Andrew Lunn:
> On Wed, Apr 22, 2026 at 08:21:23AM +0200, Michael Fritscher wrote:
>> Good day,
>>
>> actually, I do use Xircom PCMCIA network cards (yes, the 16 bit ones)
>> on
>> Lenovo X60/X61 laptops as a second LAN card for server maintenances
>> with
>> current 64 bit distros (e.g. Debian Trixie, which I plan to update to
>> Trixie+1 when available). Why? Because I have them and they are
>> working ;-)
>
> Hi Michael
>
> I will drop this from the patchset for the moment.
>
> Would you be willing to take up the Maintainer role for it?
>
> Andrew
Hello Andrew,
thanks! If someone mentors me I could try... I have experience with C
programming, esp. in the embedded world, but (almost) no experience with
the Linux kernel development.
But regression tests etc. can be conducted by me - on 32 and 64 bit
machines. The oldest being a P120, the newest the mentioned X61 with its
C2D CPU.
Best regards
Michael
^ 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