* [PATCH net 4/7] selftests: ovpn: increase timeout
From: Matthieu Baerts (NGI0) @ 2026-07-10 18:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Shuah Khan
Cc: netdev, linux-kselftest, linux-kernel, Matthieu Baerts (NGI0),
Antonio Quartulli, Sabrina Dubroca
In-Reply-To: <20260710-net-sft-fix-containers-v1-0-a2915c294ef5@kernel.org>
The default timeout is 45 seconds, that's too low for a few ovpn tests.
Indeed, these tests can take up to 50 seconds with some debug kernel
config on NIPA. Set a timeout to 90 seconds, just to be on the safe
side.
Note that the Fixes tag here points to the introduction of the ovpn
tests because I don't know when they started to take more than 45
seconds. That's OK because a timeout of 1.5 minutes is not exaggerated.
Fixes: 959bc330a439 ("testing/selftests: add test tool and scripts for ovpn module")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
To: Antonio Quartulli <antonio@openvpn.net>
To: Sabrina Dubroca <sd@queasysnail.net>
---
tools/testing/selftests/net/ovpn/settings | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/net/ovpn/settings b/tools/testing/selftests/net/ovpn/settings
new file mode 100644
index 000000000000..ba4d85f74cd6
--- /dev/null
+++ b/tools/testing/selftests/net/ovpn/settings
@@ -0,0 +1 @@
+timeout=90
--
2.53.0
^ permalink raw reply related
* [PATCH net 3/7] selftests: ovpn: add IPV6 and VETH configs
From: Matthieu Baerts (NGI0) @ 2026-07-10 18:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Shuah Khan
Cc: netdev, linux-kselftest, linux-kernel, Matthieu Baerts (NGI0),
Antonio Quartulli, Sabrina Dubroca
In-Reply-To: <20260710-net-sft-fix-containers-v1-0-a2915c294ef5@kernel.org>
They are required to run the selftests:
- Tests are executed in v4 and v6.
- Virtual Ethernet are used between the different netns.
This has not been seen on NIPA before, because the 'ovpn' tests are
executed with the 'tcp_ao' ones, merging their config files. These two
kernel config are present in tools/testing/selftests/net/tcp_ao/config.
This issue is visible when only the ovpn config is used on top of the
default one. This is the recommended way to execute selftest targets.
Fixes: 959bc330a439 ("testing/selftests: add test tool and scripts for ovpn module")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
To: Antonio Quartulli <antonio@openvpn.net>
To: Sabrina Dubroca <sd@queasysnail.net>
---
tools/testing/selftests/net/ovpn/config | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/net/ovpn/config b/tools/testing/selftests/net/ovpn/config
index d6cf033d555e..6b424762e46e 100644
--- a/tools/testing/selftests/net/ovpn/config
+++ b/tools/testing/selftests/net/ovpn/config
@@ -4,6 +4,7 @@ CONFIG_CRYPTO_CHACHA20POLY1305=y
CONFIG_CRYPTO_GCM=y
CONFIG_DST_CACHE=y
CONFIG_INET=y
+CONFIG_IPV6=y
CONFIG_NET=y
CONFIG_NETFILTER=y
CONFIG_NET_UDP_TUNNEL=y
@@ -11,3 +12,4 @@ CONFIG_NF_TABLES=m
CONFIG_NF_TABLES_INET=y
CONFIG_OVPN=m
CONFIG_STREAM_PARSER=y
+CONFIG_VETH=y
--
2.53.0
^ permalink raw reply related
* [PATCH net 2/7] selftests: openvswitch: add config file
From: Matthieu Baerts (NGI0) @ 2026-07-10 18:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Shuah Khan
Cc: netdev, linux-kselftest, linux-kernel, Matthieu Baerts (NGI0),
Aaron Conole, Eelco Chaudron, Ilya Maximets, dev
In-Reply-To: <20260710-net-sft-fix-containers-v1-0-a2915c294ef5@kernel.org>
The kselftests doc mentions that a config file should be present "if a
test needs specific kernel config options enabled". This selftest
requires some kernel config, but no config file was provided.
We could say that a sub-target could use the parent's config file, but
the kselftests doc doesn't mention anything about that. Plus the
net/openvswitch target is the only net target without a config file.
Here is a new config file, which is a trimmed version of the net one,
with hopefully the minimal required kconfig on top of 'make defconfig'.
The Fixes tag points to the introduction of the net/openvswitch target,
just to help validating this target on stable kernels.
Fixes: 25f16c873fb1 ("selftests: add openvswitch selftest suite")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
To: Aaron Conole <aconole@redhat.com>
To: Eelco Chaudron <echaudro@redhat.com>
To: Ilya Maximets <i.maximets@ovn.org>
Cc: dev@openvswitch.org
---
tools/testing/selftests/net/openvswitch/config | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/tools/testing/selftests/net/openvswitch/config b/tools/testing/selftests/net/openvswitch/config
new file mode 100644
index 000000000000..c659749cd086
--- /dev/null
+++ b/tools/testing/selftests/net/openvswitch/config
@@ -0,0 +1,16 @@
+CONFIG_GENEVE=m
+CONFIG_INET_DIAG=y
+CONFIG_IPV6=y
+CONFIG_NETFILTER=y
+CONFIG_NET_IPGRE=m
+CONFIG_NET_IPGRE_DEMUX=m
+CONFIG_NF_CONNTRACK=m
+CONFIG_NF_CONNTRACK_OVS=y
+CONFIG_OPENVSWITCH=m
+CONFIG_OPENVSWITCH_GENEVE=m
+CONFIG_OPENVSWITCH_GRE=m
+CONFIG_OPENVSWITCH_VXLAN=m
+CONFIG_PSAMPLE=m
+CONFIG_VETH=y
+CONFIG_VLAN_8021Q=y
+CONFIG_VXLAN=m
--
2.53.0
^ permalink raw reply related
* [PATCH net 1/7] selftests: af_unix: add USER_NS config
From: Matthieu Baerts (NGI0) @ 2026-07-10 18:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Shuah Khan
Cc: netdev, linux-kselftest, linux-kernel, Matthieu Baerts (NGI0),
Kuniyuki Iwashima
In-Reply-To: <20260710-net-sft-fix-containers-v1-0-a2915c294ef5@kernel.org>
This is required to use unshare(CLONE_NEWUSER).
This has not been seen on NIPA before, because the 'af_unix' tests are
executed with the 'net' ones, merging their config files. USER_NS is
present in tools/testing/selftests/net/config.
This issue is visible when only the af_unix config is used on top of the
default one. This is the recommended way to execute selftest targets.
Fixes: ac011361bd4f ("af_unix: Add test for sock_diag and UDIAG_SHOW_UID.")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
To: Kuniyuki Iwashima <kuniyu@google.com>
---
tools/testing/selftests/net/af_unix/config | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/net/af_unix/config b/tools/testing/selftests/net/af_unix/config
index b5429c15a53c..41dbb03c747e 100644
--- a/tools/testing/selftests/net/af_unix/config
+++ b/tools/testing/selftests/net/af_unix/config
@@ -1,3 +1,4 @@
CONFIG_AF_UNIX_OOB=y
CONFIG_UNIX=y
CONFIG_UNIX_DIAG=m
+CONFIG_USER_NS=y
--
2.53.0
^ permalink raw reply related
* [PATCH net 0/7] selftests: net: add missing kconfig and settings
From: Matthieu Baerts (NGI0) @ 2026-07-10 18:04 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Shuah Khan
Cc: netdev, linux-kselftest, linux-kernel, Matthieu Baerts (NGI0),
Kuniyuki Iwashima, Aaron Conole, Eelco Chaudron, Ilya Maximets,
dev, Antonio Quartulli, Sabrina Dubroca, Andrew Lunn,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Mohsin Bashir, David Wei,
Wei Wang, bpf, Breno Leitao, Andre Carvalho
When trying to execute the same selftests targets as the ones executed
on NIPA, but using containers with minimal tools, I got some issues
with a few tests.
Most of these issues are due to missing kernel config, but also too
short timeout:
- For the kconfig, these issues were not visible on NIPA, because some
targets are executed in the same runner, using the same kernel: the
config files of the different targets are merged. On my side, I
followed the recommended way, and only used the config file on top of
a 'make defconfig', revealing some missing kconfig's.
- For the timeout, that was not visible on NIPA either because the
Netdev machines are very powerful and the timeout is doubled when
using a debug kernel config (ovpn case), or because there are some
custom values on the test branches only (drv-net).
While at it, add an extra patch to display an error message in case of
failure with some netconsole scripts.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Matthieu Baerts (NGI0) (7):
selftests: af_unix: add USER_NS config
selftests: openvswitch: add config file
selftests: ovpn: add IPV6 and VETH configs
selftests: ovpn: increase timeout
selftests: drv-net: increase timeout
selftests: drv-net: add missing kconfig for psp.py
selftests: netconsole: ignore busywait errors
tools/testing/selftests/drivers/net/config | 3 +++
.../selftests/drivers/net/netconsole/netcons_cmdline.sh | 2 +-
.../drivers/net/netconsole/netcons_fragmented_msg.sh | 4 ++--
.../selftests/drivers/net/netconsole/netcons_resume.sh | 2 +-
.../selftests/drivers/net/netconsole/netcons_sysdata.sh | 2 +-
tools/testing/selftests/drivers/net/settings | 1 +
tools/testing/selftests/net/af_unix/config | 1 +
tools/testing/selftests/net/openvswitch/config | 16 ++++++++++++++++
tools/testing/selftests/net/ovpn/config | 2 ++
tools/testing/selftests/net/ovpn/settings | 1 +
10 files changed, 29 insertions(+), 5 deletions(-)
---
base-commit: 1cd23ca80784223fa2204e16203f754da4e821f8
change-id: 20260709-net-sft-fix-containers-2b4261007fec
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
^ permalink raw reply
* RE: [PATCH net v3 2/3] net: ethernet: oa_tc6: Improvement in buffer overflow handling
From: Selvamani Rajagopal @ 2026-07-10 18:03 UTC (permalink / raw)
To: Simon Horman
Cc: parthiban.veerasooran@microchip.com, andrew+netdev@lunn.ch,
Piergiorgio Beruto, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, andrew@lunn.ch,
Parthiban.Veerasooran@microchip.com
In-Reply-To: <20260710142019.1619159-1-horms@kernel.org>
> -----Original Message-----
> From: Simon Horman <horms@kernel.org>
> Sent: Friday, July 10, 2026 7:20 AM
> To: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> Cc: Simon Horman <horms@kernel.org>; parthiban.veerasooran@microchip.com;
>
> [High]
> Now that oa_tc6_prcs_rx_frame_end() returns int (and can return -EAGAIN
> via oa_tc6_update_rx_skb() when tail + size > end), should the
> "previous rx frame end + next rx frame start" branch also observe the
> return value? That branch is not shown in the diff, but in the
> resulting file it reads:
No need to check the return value. My comment below gives the reason.
>
> If oa_tc6_prcs_rx_frame_end() here returns -EAGAIN, oa_tc6_look_for_new_frame()
> has already set tc6->rx_buf_overflow = true and cleared rx_skb. Execution
> then falls through to oa_tc6_prcs_rx_frame_start(), which allocates a
> fresh rx_skb and copies the start bytes, but tc6->rx_buf_overflow stays
> true because the guard
Yes. This is an issue. I will clear the rx_buf_overflow to false as the condition
for clearing is to see a start_valid bit (a.k.a new frame). And we have a new frame
to process at this stage.
>
> [Medium]
> Is it intentional that a real -ENOMEM from oa_tc6_prcs_rx_chunk_payload()
> (originating in oa_tc6_allocate_rx_skb() -> netdev_alloc_skb_ip_align())
> is now folded into the retry path and converted to -EAGAIN at the end
> of this function?
Yes. It is intentional. Code changes attempt to recover from either ENOMEM or
EAGAIN. Recovery actions on both errors, are same. I will add some more comment
to make it clear.
>
> Before this patch, -ENOMEM propagated up through oa_tc6_try_spi_transfer()
> and produced a netdev_err("Device error: %d", ret) plus
> oa_tc6_free_ongoing_skbs() cleanup. With this change, the outer while
> loop treats -EAGAIN as non-fatal, so sustained memory exhaustion is
> reported only as increments to stats.rx_dropped from
> oa_tc6_allocate_rx_skb().
>
> The commit message describes the change as being about buffer overflow
> errors; is the change in visibility for allocation failures intended?
Maybe I will change the commit message as "improvement in error recovery"
> > }
>
> [High]
> Can this unconditional oa_tc6_look_for_new_frame() discard a frame that
> was successfully started later in the same buffer?
>
> guard in oa_tc6_prcs_rx_chunk_payload() until yet another start_valid
> arrives. Would it be safer to only call oa_tc6_look_for_new_frame()
> here if the last iteration was still in an errored state, e.g. by
> tracking the outcome of the most recent chunk rather than an aggregate
> retry flag?
I don't think there is no "best method" to solve this issue. But I am open to
suggestions. In my view, we may have many data chunks with buffer overflow
set, not just one or two. It is hard to tell whether every chunk with overflow error
has good (or bad) data.
Code treats the data chunk as good if there is no "bad header" bit set, and "data valid"
bit is set, which I think is fair.
Here are the choices I see
1) Original code: Discarded all the received chunks once we see overflow error.
2) Current change: Let the loop recover as many frames as possible from
the data chunks received. At the end of the loop, we trash what is left. Yes. It is
possible that we may trash a last one that may be a good one.
3) What Sashiko says: Ignore chunk errors in the middle or beginning of the loop.
Just worry about the recent chunk with error.
I don't think we can accurately tell whether 2 is better or 3. It may entirely depend on
how many chunks are set with overflow error it at any given time.
I can change the Implementation if someone thinks #3 is better.
>
> [ ... ]
^ permalink raw reply
* Re: [PATCH net-next v14 0/9] tls: Add TLS 1.3 hardware offload support
From: Rishikesh Jethwani @ 2026-07-10 17:56 UTC (permalink / raw)
To: Nils Juenemann
Cc: borisp, davem, edumazet, john.fastabend, kuba, leon, mbloch,
netdev, pabeni, saeedm, sd, tariqt
In-Reply-To: <20260708060319.68063-1-nils.juenemann@gmail.com>
On Tue, Jul 7, 2026 at 11:03 PM Nils Juenemann <nils.juenemann@gmail.com> wrote:
>
> On Tue, Jul 7, 2026 at 5:31 PM Rishikesh Jethwani <rjethwani@everpuredata.com> wrote:
> >
> > Could you post the disassembly [...] count how many distinct loads of
> > sk+0x4f8 the compiler emitted in that region.
>
> objdump of mlx5e_ktls_handle_rx_skb, CQE_TLS_OFFLOAD_RESYNC branch
> (+0x63) through RIP+0x10a; bytes match the oops Code around the fault:
>
> 11bd03: 48 83 82 90 01 00 00 addq $0x1,0x190(%rdx)
> 11bd0a: 01
> 11bd0b: 48 8b b6 d0 00 00 00 mov 0xd0(%rsi),%rsi
> 11bd12: 49 89 fc mov %rdi,%r12
> 11bd15: 4c 8b b7 00 01 00 00 mov 0x100(%rdi),%r14
> 11bd1c: 0f b7 46 0c movzwl 0xc(%rsi),%eax
> 11bd20: 4d 8b be 08 01 00 00 mov 0x108(%r14),%r15
> 11bd27: 66 3d 81 00 cmp $0x81,%ax
> 11bd2b: 0f 84 a4 01 00 00 je 11bed5 <mlx5e_ktls_handle_rx_skb+0x235>
> 11bd31: 66 3d 88 a8 cmp $0xa888,%ax
> 11bd35: 0f 84 9a 01 00 00 je 11bed5 <mlx5e_ktls_handle_rx_skb+0x235>
> 11bd3b: 0f b7 43 78 movzwl 0x78(%rbx),%eax
> 11bd3f: 49 89 c5 mov %rax,%r13
> 11bd42: 48 01 c6 add %rax,%rsi
> 11bd45: 45 8b 8e e0 00 00 00 mov 0xe0(%r14),%r9d
> 11bd4c: 0f b6 06 movzbl (%rsi),%eax
> 11bd4f: 83 e0 f0 and $0xfffffff0,%eax
> 11bd52: 3c 40 cmp $0x40,%al
> 11bd54: 0f 84 a8 01 00 00 je 11bf02 <mlx5e_ktls_handle_rx_skb+0x262>
> 11bd5a: 44 0f b7 46 2a movzwl 0x2a(%rsi),%r8d
> 11bd5f: 41 8d 45 28 lea 0x28(%r13),%eax
> 11bd63: 0f b7 56 28 movzwl 0x28(%rsi),%edx
> 11bd67: 4c 89 ff mov %r15,%rdi
> 11bd6a: 89 45 d4 mov %eax,-0x2c(%rbp)
> 11bd6d: 48 8d 4e 18 lea 0x18(%rsi),%rcx
> 11bd71: 4c 8d 76 28 lea 0x28(%rsi),%r14
> 11bd75: 48 83 c6 08 add $0x8,%rsi
> 11bd79: 6a 00 push $0x0
> 11bd7b: 66 41 c1 c0 08 rol $0x8,%r8w
> 11bd80: 45 0f b7 c0 movzwl %r8w,%r8d
> 11bd84: e8 00 00 00 00 call 11bd89 <mlx5e_ktls_handle_rx_skb+0xe9>
> 11bd89: 49 89 c7 mov %rax,%r15
> 11bd8c: 58 pop %rax
> 11bd8d: 4d 85 ff test %r15,%r15
> 11bd90: 0f 84 4a ff ff ff je 11bce0 <mlx5e_ktls_handle_rx_skb+0x40>
> 11bd96: 41 0f b6 47 12 movzbl 0x12(%r15),%eax
> 11bd9b: 3c 06 cmp $0x6,%al
> 11bd9d: 0f 84 cc 00 00 00 je 11be6f <mlx5e_ktls_handle_rx_skb+0x1cf>
> 11bda3: 49 8b 87 f8 04 00 00 mov 0x4f8(%r15),%rax
> 11bdaa: 48 8b 40 30 mov 0x30(%rax),%rax
>
> One load of sk+0x4f8 in this range, at 11bda3 (the fault). r15 only
> becomes sk at 11bd89 (mov %rax,%r15), so there is no sk+0x4f8
> dereference before 11bda3 in this range. The only other sk+0x4f8
> load in the function is 11be20, after the fault and not reached. So my
> earlier "two independent loads, second reading NULL" was wrong.
>
> Thanks,
> Nils
resync_update_sn() handles CQE_TLS_OFFLOAD_RESYNC by looking up the
socket with inet_lookup_established() / __inet6_lookup_established()
and then dereferencing tls_get_ctx(sk) on the assumption that the
returned socket owns the TLS context that produced the CQE.
That assumption is not guaranteed. The established lookup matches only
on the 5-tuple and does not filter on TLS ULP state, so it can return a
TCP_ESTABLISHED socket with no TLS context attached. In that case
tls_get_ctx(sk) is NULL and the RX resync path dereferences it.
In the observed crash, the returned socket was TCP_ESTABLISHED with both
icsk_ulp_ops and icsk_ulp_data NULL, i.e. a socket without a TLS ULP
attached at lookup time. This can happen if a stale resync CQE is
matched to a different socket for the same 5-tuple, or otherwise
resolves to a socket without a TLS context.
Fetch tls_get_ctx(sk) once after the TIME_WAIT check and bail out if it
is NULL, then pass the sampled tls_context down to the resync helpers.
Patch:
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
index c0676148a36e..754b6a45f604 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
@@ -478,12 +478,12 @@ void mlx5e_ktls_handle_get_psv_completion(struct
mlx5e_icosq_wqe_info *wi,
/* Runs in NAPI.
* Function elevates the refcount, unless no work is queued.
*/
-static bool resync_queue_get_psv(struct sock *sk)
+static bool resync_queue_get_psv(struct tls_context *tls_ctx)
{
struct mlx5e_ktls_offload_context_rx *priv_rx;
struct mlx5e_ktls_rx_resync_ctx *resync;
- priv_rx = mlx5e_get_ktls_rx_priv_ctx(tls_get_ctx(sk));
+ priv_rx = mlx5e_get_ktls_rx_priv_ctx(tls_ctx);
if (unlikely(!priv_rx))
return false;
@@ -507,6 +507,7 @@ static void resync_update_sn(struct mlx5e_rq *rq,
struct sk_buff *skb)
struct tls_offload_resync_async *resync_async;
struct net_device *netdev = rq->netdev;
struct net *net = dev_net(netdev);
+ struct tls_context *tls_ctx;
struct sock *sk = NULL;
unsigned int datalen;
struct iphdr *iph;
@@ -545,12 +546,20 @@ static void resync_update_sn(struct mlx5e_rq
*rq, struct sk_buff *skb)
if (unlikely(sk->sk_state == TCP_TIME_WAIT))
goto unref;
- if (unlikely(!resync_queue_get_psv(sk)))
+ /* Established lookup is tuple-based and may return a socket without
+ * a TLS ULP attached. Sample the TLS context once and bail out if
+ * none is present.
+ */
+ tls_ctx = tls_get_ctx(sk);
+ if (unlikely(!tls_ctx))
+ goto unref;
+
+ if (unlikely(!resync_queue_get_psv(tls_ctx)))
goto unref;
seq = th->seq;
datalen = skb->len - depth;
- resync_async = tls_offload_ctx_rx(tls_get_ctx(sk))->resync_async;
+ resync_async = tls_offload_ctx_rx(tls_ctx)->resync_async;
tls_offload_rx_resync_async_request_start(resync_async, seq, datalen);
rq->stats->tls_resync_req_start++;
^ permalink raw reply related
* [PATCH net] nfc: llcp: validate TLV length before parsing to fix OOB read
From: Weiming Shi @ 2026-07-10 17:55 UTC (permalink / raw)
To: David Heidelberg, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: oe-linux-nfc, netdev, linux-kernel, xmei5, Weiming Shi
nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() iterate over
a TLV array supplied by the remote peer. Each iteration reads the type
and length from tlv[0]/tlv[1] and then advances by length + 2, but the
loop only tests offset < tlv_array_len and never checks that the 2-byte
header fits in the remaining space. A truncated trailing entry is enough
to read past the buffer on the tlv[1] access.
The length byte then makes it worse. offset is a u8, so length + 2 wraps
at 256: length == 0xff advances by 0x101 and leaves offset unchanged, so
the loop stays live while tlv keeps moving forward. The parse walks well
past the buffer, and the next iteration's tlv[0]/tlv[1] read lands out of
bounds rather than the walk stopping one entry over.
nfc_llcp_parse_gb_tlv() runs on the general bytes of an activated
NFC-DEP link. An RF_INTF_ACTIVATED_NTF in listen mode reaches it via
nci_ntf_packet() -> nfc_tm_activated() -> nfc_llcp_set_remote_gb(), which
copies the peer's general bytes into the 48-byte remote_gb[] field of the
heap-allocated struct nfc_llcp_local; the wrapped walk runs off the end
of that allocation. nfc_llcp_parse_connection_tlv() is reached the same
way from CONNECT/CC PDUs, over tlv data taken from the received skb.
Bound each iteration to tlv_array_len before touching the header, and
widen offset to u16 so the advance can no longer wrap. Well-formed TLVs
are parsed as before; a malformed trailing entry ends the loop.
BUG: KASAN: slab-out-of-bounds in nfc_llcp_parse_gb_tlv (net/nfc/llcp_commands.c:204)
Read of size 1 by task kworker/u8:3
nfc_llcp_parse_gb_tlv (net/nfc/llcp_commands.c:204)
nfc_llcp_set_remote_gb (net/nfc/llcp_core.c:681)
nfc_tm_activated (net/nfc/core.c:643 net/nfc/core.c:677)
nci_ntf_packet (net/nfc/nci/ntf.c:883 net/nfc/nci/ntf.c:1015)
nci_rx_work (net/nfc/nci/core.c:1564)
Fixes: d646960f7986 ("NFC: Initial LLCP support")
Reported-by: Xiang Mei <xmei5@asu.edu>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
net/nfc/llcp_commands.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_commands.c
index 291f26facbf3..3f0f8eef9890 100644
--- a/net/nfc/llcp_commands.c
+++ b/net/nfc/llcp_commands.c
@@ -193,17 +193,21 @@ int nfc_llcp_parse_gb_tlv(struct nfc_llcp_local *local,
const u8 *tlv_array, u16 tlv_array_len)
{
const u8 *tlv = tlv_array;
- u8 type, length, offset = 0;
+ u8 type, length;
+ u16 offset = 0;
pr_debug("TLV array length %d\n", tlv_array_len);
if (local == NULL)
return -ENODEV;
- while (offset < tlv_array_len) {
+ while (offset + 2 <= tlv_array_len) {
type = tlv[0];
length = tlv[1];
+ if (offset + 2 + length > tlv_array_len)
+ break;
+
pr_debug("type 0x%x length %d\n", type, length);
switch (type) {
@@ -243,17 +247,21 @@ int nfc_llcp_parse_connection_tlv(struct nfc_llcp_sock *sock,
const u8 *tlv_array, u16 tlv_array_len)
{
const u8 *tlv = tlv_array;
- u8 type, length, offset = 0;
+ u8 type, length;
+ u16 offset = 0;
pr_debug("TLV array length %d\n", tlv_array_len);
if (sock == NULL)
return -ENOTCONN;
- while (offset < tlv_array_len) {
+ while (offset + 2 <= tlv_array_len) {
type = tlv[0];
length = tlv[1];
+ if (offset + 2 + length > tlv_array_len)
+ break;
+
pr_debug("type 0x%x length %d\n", type, length);
switch (type) {
--
2.43.0
^ permalink raw reply related
* [PATCH net v4] tipc: serialize udp bearer replicast list updates
From: Weiming Shi @ 2026-07-10 17:47 UTC (permalink / raw)
To: Jon Maloy, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: netdev, tipc-discussion, linux-kernel, Tung Nguyen, xmei5,
Weiming Shi
tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with
list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs
from the encap receive softirq (via tipc_udp_rcast_disc()) without
rtnl_lock(), so it can race the cleanup delete and corrupt the list:
list_del corruption. prev->next should be ffff8880298d7ab8,
but was ffff88802449ad38. (prev=ffff888027e3ec98)
kernel BUG at lib/list_debug.c:62!
RIP: __list_del_entry_valid_or_report+0x17a/0x200
Workqueue: events cleanup_bearer
Call Trace:
cleanup_bearer (net/tipc/udp_media.c:811)
process_one_work (kernel/workqueue.c:3302)
worker_thread (kernel/workqueue.c:3466)
The bearer can be enabled from an unprivileged user namespace, as the
TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM.
Add a spinlock to struct udp_bearer and take it around the list_add_rcu()
in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so
the two writers can no longer corrupt the list.
Reject a duplicate peer under the same lock before allocating, and remove
tipc_udp_is_known_peer(). The old lockless pre-check in
tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer
could both find it absent and add it twice. Doing the check under
rcast_lock in tipc_udp_rcast_add(), before the allocation, makes it the
single point of truth for both the discovery and the netlink add paths and
keeps a flood of the same address from churning the allocator.
Fixes: ef20cd4dd163 ("tipc: introduce UDP replicast")
Reported-by: Xiang Mei <xmei5@asu.edu>
Suggested-by: Tung Nguyen <tung.quang.nguyen@est.tech>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
v4: (per Tung's review)
- Reject a duplicate under rcast_lock before allocating rcast, so a
flood of the same address can't churn the allocator.
v3:
- Check for a duplicate peer in tipc_udp_rcast_add() under rcast_lock
and remove tipc_udp_is_known_peer().
v2:
- Narrow the lock to the list mutation.
net/tipc/udp_media.c | 53 ++++++++++++++++++++------------------------
1 file changed, 24 insertions(+), 29 deletions(-)
diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
index 62ae7f5b5..3f0d75d72 100644
--- a/net/tipc/udp_media.c
+++ b/net/tipc/udp_media.c
@@ -94,6 +94,7 @@ struct udp_replicast {
* @ifindex: local address scope
* @work: used to schedule deferred work on a bearer
* @rcast: associated udp_replicast container
+ * @rcast_lock: serialize updates to @rcast.list against concurrent updaters
*/
struct udp_bearer {
struct tipc_bearer __rcu *bearer;
@@ -101,6 +102,7 @@ struct udp_bearer {
u32 ifindex;
struct work_struct work;
struct udp_replicast rcast;
+ spinlock_t rcast_lock; /* protects rcast.list */
};
static int tipc_udp_is_mcast_addr(struct udp_media_addr *addr)
@@ -278,26 +280,6 @@ static int tipc_udp_send_msg(struct net *net, struct sk_buff *skb,
return err;
}
-static bool tipc_udp_is_known_peer(struct tipc_bearer *b,
- struct udp_media_addr *addr)
-{
- struct udp_replicast *rcast, *tmp;
- struct udp_bearer *ub;
-
- ub = rcu_dereference_rtnl(b->media_ptr);
- if (!ub) {
- pr_err_ratelimited("UDP bearer instance not found\n");
- return false;
- }
-
- list_for_each_entry_safe(rcast, tmp, &ub->rcast.list, list) {
- if (!memcmp(&rcast->addr, addr, sizeof(struct udp_media_addr)))
- return true;
- }
-
- return false;
-}
-
static int tipc_udp_rcast_add(struct tipc_bearer *b,
struct udp_media_addr *addr)
{
@@ -308,16 +290,34 @@ static int tipc_udp_rcast_add(struct tipc_bearer *b,
if (!ub)
return -ENODEV;
+ /* Serialize with other updaters and reject a duplicate before
+ * allocating, so a flood of the same address can't churn the
+ * allocator.
+ */
+ spin_lock_bh(&ub->rcast_lock);
+ list_for_each_entry(rcast, &ub->rcast.list, list) {
+ if (!memcmp(&rcast->addr, addr, sizeof(*addr))) {
+ spin_unlock_bh(&ub->rcast_lock);
+ return 0;
+ }
+ }
+
rcast = kmalloc_obj(*rcast, GFP_ATOMIC);
- if (!rcast)
+ if (!rcast) {
+ spin_unlock_bh(&ub->rcast_lock);
return -ENOMEM;
+ }
if (dst_cache_init(&rcast->dst_cache, GFP_ATOMIC)) {
+ spin_unlock_bh(&ub->rcast_lock);
kfree(rcast);
return -ENOMEM;
}
memcpy(&rcast->addr, addr, sizeof(struct udp_media_addr));
+ list_add_rcu(&rcast->list, &ub->rcast.list);
+ b->bcast_addr.broadcast = TIPC_REPLICAST_SUPPORT;
+ spin_unlock_bh(&ub->rcast_lock);
if (ntohs(addr->proto) == ETH_P_IP)
pr_info("New replicast peer: %pI4\n", &rcast->addr.ipv4);
@@ -325,8 +325,6 @@ static int tipc_udp_rcast_add(struct tipc_bearer *b,
else if (ntohs(addr->proto) == ETH_P_IPV6)
pr_info("New replicast peer: %pI6\n", &rcast->addr.ipv6);
#endif
- b->bcast_addr.broadcast = TIPC_REPLICAST_SUPPORT;
- list_add_rcu(&rcast->list, &ub->rcast.list);
return 0;
}
@@ -361,9 +359,6 @@ static int tipc_udp_rcast_disc(struct tipc_bearer *b, struct sk_buff *skb)
return 0;
}
- if (likely(tipc_udp_is_known_peer(b, &src)))
- return 0;
-
return tipc_udp_rcast_add(b, &src);
}
@@ -644,9 +639,6 @@ int tipc_udp_nl_bearer_add(struct tipc_bearer *b, struct nlattr *attr)
return -EINVAL;
}
- if (tipc_udp_is_known_peer(b, &addr))
- return 0;
-
return tipc_udp_rcast_add(b, &addr);
}
@@ -679,6 +671,7 @@ static int tipc_udp_enable(struct net *net, struct tipc_bearer *b,
return -ENOMEM;
INIT_LIST_HEAD(&ub->rcast.list);
+ spin_lock_init(&ub->rcast_lock);
if (!attrs[TIPC_NLA_BEARER_UDP_OPTS])
goto err;
@@ -819,10 +812,12 @@ static void cleanup_bearer(struct work_struct *work)
struct udp_replicast *rcast, *tmp;
struct tipc_net *tn;
+ spin_lock_bh(&ub->rcast_lock);
list_for_each_entry_safe(rcast, tmp, &ub->rcast.list, list) {
list_del_rcu(&rcast->list);
call_rcu_hurry(&rcast->rcu, rcast_free_rcu);
}
+ spin_unlock_bh(&ub->rcast_lock);
tn = tipc_net(sock_net(ub->sk));
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net v3] mptcp: only set DATA_FIN when a mapping is present
From: Matthieu Baerts @ 2026-07-10 17:30 UTC (permalink / raw)
To: Michael Bommarito
Cc: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Gang Yan, mptcp,
netdev, linux-kernel
In-Reply-To: <CAJJ9bXxYfCPgh6ZsMCXf6YrpEPPzKmOcDwD0L1cNcWAefBFTLg@mail.gmail.com>
On 10/07/2026 19:17, Michael Bommarito wrote:
> On Fri, Jul 10, 2026 at 12:19 PM Matthieu Baerts <matttbe@kernel.org> wrote:
>>
>> I tried to reproduce it on my side using packetdrill-mptcp [1], but I
>> was not able to test with KMSAN: my kernel boot, but is stuck when KMSAN
>> is enabled... By chance, if you can try this reproducer on your side,
>> with and without your patched kernel, that would be great :)
>>
>> [1] https://github.com/multipath-tcp/packetdrill/pull/203
>
> Can you try with more RAM and make sure that you have these set too?
>
> CONFIG_CRYPTO_USER_API=y
> CONFIG_CRYPTO_USER_API_HASH=y
Thank you for the suggestion. Yes, I did use more RAM (just tried with
8G just to be sure), and with the CRYPTO_USER_API (needed for
packetdrill), but the VM stalls at boot time:
Starting KernelMemorySanitizer
ATTENTION: KMSAN is a debugging tool! Do not use it on production
machines!
I didn't investigate more, but I'm using KMSAN on another similar
machine with syzkaller without issues.
> I was able to get your PR #203 test to trigger after using -m 8G +
> AF_ALG under vng
Nice, thank you for having checked that! I guess I can merge this PR then.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply
* Re: [PATCH net v2] gve: fix Rx queue stall on alloc failure
From: Eddie Phillips @ 2026-07-10 17:23 UTC (permalink / raw)
To: Przemek Kitszel
Cc: Harshitha Ramamurthy, joshwash, andrew+netdev, davem, edumazet,
kuba, pabeni, willemb, jordanrhee, netdev, nktgrg, maolson,
thostet, csully, bcf, maciej.fijalkowski, linux-kernel, stable
In-Reply-To: <0f0e1e47-2f96-44cd-9337-c3d910f1e202@intel.com>
On Fri, Jul 10, 2026 at 7:24 AM Przemek Kitszel
<przemyslaw.kitszel@intel.com> wrote:
>
>
> > @@ -400,6 +414,26 @@ void gve_rx_post_buffers_dqo(struct gve_rx_ring *rx)
> > }
> >
> > rx->fill_cnt += num_posted;
> > +
> > + /* If the queue has fewer than GVE_RX_BUF_THRESH_DQO descriptors
> > + * visible to the hardware, the hardware is in danger of starving
> > + * and cannot trigger interrupts.
> > + *
> > + * We use a threshold of 32 because a single maximum-sized RSC
> > + * packet can consume up to 19 descriptors in the Rx path. Lower
> > + * thresholds (e.g., 8 or 16) would be unsafe as they could cause
> > + * the device to drop/stall on a maximum-sized RSC packet.
> > + *
> > + * Start the timer to periodically reschedule NAPI and recover.
> > + */
> > + num_bufs_avail_to_hw =
> > + ((bufq->tail & ~(GVE_RX_BUF_THRESH_DQO - 1)) -
> > + bufq->head) & bufq->mask;
> > +
> > + if (num_bufs_avail_to_hw < GVE_RX_BUF_THRESH_DQO) {
>
> nice bit-arith tricks, but perhaps a simpler condiion like:
> if (num_avail_slots + num_posted < GVE_RX_BUF_THRESH_DQO)
> would be sufficient?
>
Descriptors are only committed to the hardware in batches matching the
doorbell notification stride. Masking is necessary because `num_avail_slots
+ num_posted` falsely includes buffers that are written to the ring but not yet
doorbelled. We don't want the driver to overestimate the hardware's active
buffer count, fail to arm the watchdog timer, and trigger a silent rx deadlock
under memory pressure.
> > + mod_timer(&rx->starvation_timer,
> > + jiffies + msecs_to_jiffies(GVE_RX_NAPI_RESCHED_MS));
> > + }
> > }
^ permalink raw reply
* Re: [PATCH net v3] mptcp: only set DATA_FIN when a mapping is present
From: Michael Bommarito @ 2026-07-10 17:17 UTC (permalink / raw)
To: Matthieu Baerts
Cc: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Gang Yan, mptcp,
netdev, linux-kernel
In-Reply-To: <5bb0177a-8d42-4301-8cf1-db4630f18437@kernel.org>
On Fri, Jul 10, 2026 at 12:19 PM Matthieu Baerts <matttbe@kernel.org> wrote:
>
> I tried to reproduce it on my side using packetdrill-mptcp [1], but I
> was not able to test with KMSAN: my kernel boot, but is stuck when KMSAN
> is enabled... By chance, if you can try this reproducer on your side,
> with and without your patched kernel, that would be great :)
>
> [1] https://github.com/multipath-tcp/packetdrill/pull/203
Can you try with more RAM and make sure that you have these set too?
CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
I was able to get your PR #203 test to trigger after using -m 8G +
AF_ALG under vng
BUG: KMSAN: uninit-value in mptcp_incoming_options+0x1da9
mptcp_incoming_options
tcp_data_queue
tcp_rcv_established
tcp_v4_do_rcv
tcp_v4_rcv
ip_protocol_deliver_rcu
ip_local_deliver_finish
ip_local_deliver
ip_rcv
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: dsa: mt7530: add EN7528 support
From: Andrew Lunn @ 2026-07-10 17:04 UTC (permalink / raw)
To: Ahmed Naseef
Cc: netdev, Arınç ÜNAL, Chester A. Unal,
David S. Miller, AngeloGioacchino Del Regno, Conor Dooley,
DENG Qingfang, Daniel Golle, Eric Dumazet, Jakub Kicinski,
Krzysztof Kozlowski, Landen Chao, Matthias Brugger, Paolo Abeni,
Rob Herring, Russell King, Sean Wang, Vladimir Oltean, devicetree,
linux-arm-kernel, linux-kernel, linux-mediatek
In-Reply-To: <alEktKWsrriHdR40@DESKTOP-TIT0J8O.localdomain>
> My plan for v2 is to not advertise lpi_capabilities for the EN7528, so
> mac_supports_eee stays false by design and phylink disables EEE on
> these PHYs via phy_disable_eee() and refuses to enable it from
> userspace. Does that sound like the right approach to you, or would
> you prefer it handled differently?
That sounds like the correct thing to do.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v6 2/7] net: phy: phylink: add helper to modify pause
From: Andrew Lunn @ 2026-07-10 17:02 UTC (permalink / raw)
To: Maxime Chevallier
Cc: javen, hkallweit1, nic_swsd, andrew+netdev, davem, edumazet, kuba,
pabeni, horms, netdev, linux-kernel, daniel, linux, enelsonmoore,
daniel
In-Reply-To: <0c188a7d-3637-4e08-9ac8-c1d824b461ed@bootlin.com>
On Fri, Jul 10, 2026 at 12:05:06PM +0200, Maxime Chevallier wrote:
> Hi,
>
> On 7/9/26 12:02, javen wrote:
> > From: Javen Xu <javen_xu@realsil.com.cn>
> >
> > For Realtek nics, when we enable jumbo, pause are not supported. So we
> > must check the pause capabilities from ourself and lp.
> >
> > Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
> > ---
> > Changes in v5:
> > - no changes, new file
> >
> > Changes in v6:
> > - rename phylink_update_mac_pause_capabilities(), this function only
> > changes mac pause capability
> > - set asym pause and pause according to config->pause tx and rx
> > - add phydev->lock when change pl->phydev->advertising
> > ---
> > drivers/net/phy/phylink.c | 87 +++++++++++++++++++++++++++++++++++++++
> > include/linux/phylink.h | 2 +
> > 2 files changed, 89 insertions(+)
> >
> > diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> > index 59dfe35afa54..9e9cd79301d6 100644
> > --- a/drivers/net/phy/phylink.c
> > +++ b/drivers/net/phy/phylink.c
> > @@ -1828,6 +1828,93 @@ int phylink_set_fixed_link(struct phylink *pl,
> > }
> > EXPORT_SYMBOL_GPL(phylink_set_fixed_link);
> >
> > +/**
> > + * phylink_update_mac_pause_capabilities() - Dynamically update MAC pause
> > + * @pl: a pointer to a &struct phylink returned from phylink_create()
> > + * @mac_pause: the new MAC pause capabilities mask
> > + *
> > + * This function allows a MAC driver to dynamically change its pause state,
> > + * such as losing/gaining Pause frame support based on MTU size.
> > + * It recalculates supported link modes and triggers renegotiation if needed.
> > + */
> > +void phylink_update_mac_pause_capabilities(struct phylink *pl, unsigned long mac_pause)
> > +{
> > + struct phylink_link_state *config = &pl->link_config;
> > + unsigned long old_pause, caps_added, caps_removed;
> > + bool pause_adv, asym_adv;
> > +
> > + ASSERT_RTNL();
> > +
> > + if (mac_pause & ~(MAC_SYM_PAUSE | MAC_ASYM_PAUSE)) {
> > + phylink_err(pl, "Attempted to dynamically change non-pause MAC capabilities\n");
> > + return;
> > + }
> > +
> > + old_pause = pl->config->mac_capabilities & (MAC_SYM_PAUSE | MAC_ASYM_PAUSE);
> > + caps_added = mac_pause & ~old_pause;
> > + caps_removed = old_pause & ~mac_pause;
> > +
> > + if (!caps_added && !caps_removed)
> > + return;
> > +
> > + mutex_lock(&pl->state_mutex);
> > +
> > + pl->config->mac_capabilities &= ~(MAC_SYM_PAUSE | MAC_ASYM_PAUSE);
> > + pl->config->mac_capabilities |= mac_pause;
> > +
> > + if (caps_removed & MAC_SYM_PAUSE)
> > + linkmode_clear_bit(ETHTOOL_LINK_MODE_Pause_BIT, pl->supported);
> > + if (caps_removed & MAC_ASYM_PAUSE)
> > + linkmode_clear_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, pl->supported);
> > +
> > + linkmode_and(config->advertising, config->advertising, pl->supported);
> > +
> > + if (caps_added & MAC_SYM_PAUSE) {
> > + linkmode_set_bit(ETHTOOL_LINK_MODE_Pause_BIT, pl->supported);
> > + if (pl->phydev && !phylink_test(pl->phydev->supported, Pause))
> > + linkmode_clear_bit(ETHTOOL_LINK_MODE_Pause_BIT, pl->supported);
>
> Why look at what the PHY can do here ? You shouldn't need to.
I question the whole idea here. Why is this so complex? phylink should
already have all the needed code, once you change
pl->config->mac_capabilities you just need to call that code. Yes, it
might need refactoring into a helper, but that would be a preparatory
patch.
Once you start reusing existing code, i then wounder if it is just as
simple to allow any of the mac_capabilities to be changed, not just
pause?
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: dsa: mt7530: add EN7528 support
From: Ahmed Naseef @ 2026-07-10 16:58 UTC (permalink / raw)
To: Andrew Lunn
Cc: Ahmed Naseef, netdev, Arınç ÜNAL, Chester A. Unal,
David S. Miller, AngeloGioacchino Del Regno, Conor Dooley,
DENG Qingfang, Daniel Golle, Eric Dumazet, Jakub Kicinski,
Krzysztof Kozlowski, Landen Chao, Matthias Brugger, Paolo Abeni,
Rob Herring, Russell King, Sean Wang, Vladimir Oltean, devicetree,
linux-arm-kernel, linux-kernel, linux-mediatek
In-Reply-To: <f968d3fe-83dc-4b82-972b-0d4d477a1a52@lunn.ch>
On Fri, Jul 10, 2026 at 03:32:32PM +0200, Andrew Lunn wrote:
> > + /* The EN7528 LAN GPHYs advertise EEE by default, but negotiating EEE
> > + * with common link partners (e.g. Realtek GbE NICs) results in an
> > + * unstable link with dropped frames. Disable EEE advertisement on
> > + * them.
> > + */
> > + if (priv->id == ID_EN7528)
> > + for (i = EN7528_GPHY_BASE;
> > + i < EN7528_GPHY_BASE + EN7528_NUM_GPHYS; i++)
> > + mt7531_ind_c45_phy_write(priv, i, MDIO_MMD_AN,
> > + MDIO_AN_EEE_ADV, 0);
> > +
>
> The problem with this is, you can still use ethtool to enable EEE.
>
> Please look at phylink_bringup_phy(), where it calls
> phy_disable_eee().
Thanks, you are right , the register write is the wrong approach.
While looking at phylink_bringup_phy(), I noticed that the mt7530
driver sets config->lpi_capabilities but never config->lpi_interfaces.
Since
mac_supports_eee = mac_supports_eee_ops && lpi_capabilities &&
!phy_interface_empty(lpi_interfaces);
that leaves mac_supports_eee false on all mt753x ports, so phylink
already takes the phy_disable_eee() path for every port and
phylink_ethtool_set_eee() returns -EOPNOTSUPP. On the EN7528 I
confirmed "ethtool --set-eee lan1 eee on" reports "Not supported", so
EEE cannot currently be enabled from userspace on this driver at all.
That looks like it unintentionally undid the "EEE can now be enabled
using ethtool" behaviour from commit 06dfcd4098cf ("net: dsa: mt7530:
fix enabling EEE on MT7531 switch on all boards"), starting with commit
9cf21773f535 ("net: dsa: mt7530: convert to phylink managed EEE"). That
is pre-existing and outside the scope of this series, just flagging it.
For the EN7528 the GPHYs report EEE capability, but the link stops
passing traffic once LPI is entered, so EEE must stay off regardless.
The register loop cannot express that to phylib, as you noted.
My plan for v2 is to not advertise lpi_capabilities for the EN7528, so
mac_supports_eee stays false by design and phylink disables EEE on
these PHYs via phy_disable_eee() and refuses to enable it from
userspace. Does that sound like the right approach to you, or would
you prefer it handled differently?
Thanks,
Ahmed
>
> Andrew
>
> ---
> pw-bot: cr
^ permalink raw reply
* Re: [PATCH net] net: stmmac: enable the MAC on link up at 10G on 10GBASE-R
From: Andrew Lunn @ 2026-07-10 16:49 UTC (permalink / raw)
To: Maxime Chevallier
Cc: vadik likholetov, netdev, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Thierry Reding,
Jonathan Hunter, Bhadram Varka, linux-tegra, linux-kernel
In-Reply-To: <f23adbcc-6f9f-4828-8de9-b85c4450b4b7@bootlin.com>
> I suggest that instead of this fix (that is ommiting the 5G case btw), we rewrite
> the whole ctrl assignment as :
>
> switch (speed) {
> case SPEED_100000:
> ctrl |= priv->hw->link.xlgmii.speed100000;
> break;
> case SPEED_50000:
> ctrl |= priv->hw->link.xlgmii.speed50000;
> break;
> case SPEED_40000:
> ctrl |= priv->hw->link.xlgmii.speed40000;
> break;
> case SPEED_25000:
> ctrl |= priv->hw->link.xlgmii.speed25000;
> break;
> case SPEED_10000:
> ctrl |= priv->hw->link.xgmii.speed10000;
> break;
> case SPEED_5000:
> ctrl |= priv->hw->link.xgmii.speed5000;
> break;
> case SPEED_2500:
> if (interface == PHY_INTERFACE_MODE_USXGMII)
> ctrl |= priv->hw->link.xgmii.speed2500;
> else
> ctrl |= priv->hw->link.speed2500;
> break;
> case SPEED_1000:
> ctrl |= priv->hw->link.speed1000;
> case SPEED_100:
> ctrl |= priv->hw->link.speed100;
> break;
> case SPEED_10:
> ctrl |= priv->hw->link.speed10;
> break;
> default:
> return;
> }
The bug description makes it sound like it was not obvious to
debug. So maybe put an error message in the default: to aid the next
developer who hits it with SPEED_14000, or whatever comes next.
Andrew
^ permalink raw reply
* Re: [PATCH net 2/2] net: macb: mask TXUBR during TX NAPI poll to prevent IRQ storms
From: Théo Lebrun @ 2026-07-10 16:43 UTC (permalink / raw)
To: christian.taedcke, christian.taedcke-oss, Conor Dooley,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Kevin Hao, Simon Horman, Sebastian Andrzej Siewior,
Clark Williams, Steven Rostedt, Robert Hancock
Cc: netdev, linux-kernel, linux-rt-devel, stable
In-Reply-To: <20260706-upstreaming-macb-irq-storm-v1-2-ab3115b5a13a@weidmueller.com>
Hello Christian,
My biggest gripe with this patch is the commit message. It's a massive
block of text which goes here and there without enough structure.
Let me try to pick issues I have with it and try to give a better
alternative (hoping I understood the topic clearly enough).
On Mon Jul 6, 2026 at 4:02 PM CEST, Christian Taedcke via B4 Relay wrote:
> From: Christian Taedcke <christian.taedcke@weidmueller.com>
>
> macb_interrupt() defers TX completion handling to NAPI, but when it
> schedules the poll it only masks TCOMP, even though TXUBR is enabled
> alongside it (both are part of MACB_TX_INT_FLAGS). macb_tx_poll() is
> asymmetric in the same way and only re-enables TCOMP. TXUBR is thus
> left unmasked while responsibility for handling it has been deferred
> to NAPI.
Yes, so said differently:
TXUBR is acknowledged by the NAPI poll function. The IRQ signal is
active until then but signal is left unmasked. Do as with TCOMP and
mask the signal until its acknowledgment.
This sounds much more straight forward to me. And it also explains what
we do to solve the issue, which is info we expect to find in the first
commit message paragraph. The rest is to go into details onto the
specifics, the decisionmaking, etc.
> Unlike an edge event, TXUBR is a persistent condition: the controller
> keeps it asserted for as long as the transmitter reads a buffer
> descriptor whose used bit is set. Leaving a level-triggered source
> enabled while NAPI owns its processing means the interrupt refires
> immediately after the handler returns, before the poll has had a
> chance to clear the underlying condition. This turns into a hard
> interrupt storm that pegs a CPU in the (threaded) MAC IRQ handler and,
> on PREEMPT_RT, triggers RT throttling ("sched: RT throttling
> activated"), taking the network interface down.
This whole paragraph is somewhat moot to me. It highlights level versus
edge interrupts but even with edge events the bug is present: it blocks
any other IRQ from the HW until the TXUBR ACK (in NAPI context).
Describing how the bug surfaces on your HW is interesting however.
> Several situations can keep the used-bit read asserted across a poll -
> for example unreaped completed descriptors still sitting at tx_tail,
> or a transmit restart racing with macb_start_xmit(). The specific
> trigger does not matter: as long as the source stays unmasked, any
> persistent assertion is enough to storm, so the interrupt handling
> itself must be made self-limiting.
But this is unrelated? Whether TXUBR stays asserted across the poll
processing doesn't change the fact the IRQ is unmasked until we reach
NAPI context and the signal is still not ACKed.
> Mask TXUBR together with TCOMP in the IDR write when scheduling the TX
> NAPI, and re-enable both from the napi_complete path in
> macb_tx_poll(), making the TX interrupt mask/unmask symmetric and
> consistent with how the driver already treats every other
> NAPI-serviced source. The pending TXUBR is still recorded in
> queue->txubr_pending before masking and acted on by macb_tx_restart(),
> so no event is lost. A persistent TXUBR now degrades to NAPI-paced
> polling instead of a CPU-pegging hard interrupt storm.
Again a lot of words for little info. Usually the patch change
(the "mask TXUBR with TCOMP" part) belongs to the first commit message
paragraph, we shouldn't have to wait until the last paragraph to know
about what a patch does.
Some question that is left in my head after reading, that could have
been answered by your commit message: your approach of masking TXUBR
until NAPI is one way, another would have been to ACK TXUBR from
macb_interrupt(). Have you investigated that approach? The answer might
be super straight forward.
> Fixes: 138badbc21a0 ("net: macb: use NAPI for TX completion path")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Christian Taedcke <christian.taedcke@weidmueller.com>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index b11cb8f068b7..f75cf2ffdf6f 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -1971,7 +1971,7 @@ static int macb_tx_poll(struct napi_struct *napi, int budget)
> (unsigned int)(queue - bp->queues), work_done, budget);
>
> if (work_done < budget && napi_complete_done(napi, work_done)) {
> - queue_writel(queue, IER, MACB_BIT(TCOMP));
> + queue_writel(queue, IER, MACB_BIT(TCOMP) | MACB_BIT(TXUBR));
>
> /* Packet completions only seem to propagate to raise
> * interrupts when interrupts are enabled at the time, so if
> @@ -2161,7 +2161,8 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
>
> if (status & (MACB_BIT(TCOMP) |
> MACB_BIT(TXUBR))) {
> - queue_writel(queue, IDR, MACB_BIT(TCOMP));
> + queue_writel(queue, IDR, MACB_BIT(TCOMP) |
> + MACB_BIT(TXUBR));
> macb_queue_isr_clear(bp, queue, MACB_BIT(TCOMP) |
> MACB_BIT(TXUBR));
> if (status & MACB_BIT(TXUBR)) {
We risk some race condition here, but that was present before your
patch. macb_interrupt() already grabs bp->lock but macb_tx_poll() does
zero efforts. (I'm not saying that macb_tx_poll() should grab bp->lock
which would throw away the benefits of our separate queues, the solution
is more complex.)
Sashiko reports that as well.
It's not up to you to fix this. Or if you do it, it should be a separate
patch. It is weird that our IRQ handlers all grab the interface-global
bp->lock rather than a queue-specific primitive, it would probably be a
big rework.
--
TLDR: if patch 2/2 fixes your bug, I'm OK with it. Please rewrite your
commit message though. I suspect patch 1/2 is not needed.
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net v2] bnge/bng_re: fix ring ID widths
From: Andrew Lunn @ 2026-07-10 16:42 UTC (permalink / raw)
To: Vikas Gupta
Cc: gg, davem, edumazet, kuba, pabeni, andrew+netdev, horms, netdev,
linux-kernel, linux-rdma, leonro, jgg, bhargava.marreddy,
rahul-rg.gupta, vsrama-krishna.nemani, rajashekar.hudumula,
ajit.khaparde, Siva Reddy Kallam, Dharmender Garg,
Yendapally Reddy Dhananjaya Reddy
In-Reply-To: <CAHLZf_vxM0uht9S3tD02uaDWLSsYyMcCnRrwmOGhkDU4UeTbrw@mail.gmail.com>
On Fri, Jul 10, 2026 at 11:40:25AM +0530, Vikas Gupta wrote:
> Hi Andrew,
>
> On Sun, Jul 5, 2026 at 12:04 AM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > > - Backward compatibility with older firmware is not a concern.
> >
> > Could you expand on that please.
>
> The backward compatibility concern raised in v1 does not apply. Thor
> Ultra hardware has not yet been deployed and no firmware has been
> released to the field. However, future revisions of HSI must maintain
> backward compatibility.
O.K, thanks.
We take backwards compatibility seriously. The fact this hardware has
not yet escaped the laboratory, is one of the few reasons acceptable
for breaking backwards compatibility, so should be stated in the
commit message. That also avoids having to answer the question again
and again.
Andrew
^ permalink raw reply
* Re: [PATCH] docs: ACPI: DSD: motorcomm: fix docs build error
From: Andrew Lunn @ 2026-07-10 16:37 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-kernel, chunzhi.lin, Jakub Kicinski, netdev, Russell King,
linux-acpi, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman
In-Reply-To: <20260710053106.730399-1-rdunlap@infradead.org>
On Thu, Jul 09, 2026 at 10:31:06PM -0700, Randy Dunlap wrote:
> Separate the title with commas (since they are all run togethe in the
nitpick: together.
Otherwise: Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net v4] tipc: fix u16 MTU truncation in media and bearer MTU validation
From: Andrew Lunn @ 2026-07-10 16:34 UTC (permalink / raw)
To: Cen Zhang (Microsoft)
Cc: jmaloy, davem, edumazet, kuba, pabeni, horms, netdev,
tipc-discussion, linux-kernel, vadim.fedorenko, tung.quang.nguyen,
AutonomousCodeSecurity, tgopinath, kys
In-Reply-To: <20260709211649.15623-1-blbllhy@gmail.com>
On Thu, Jul 09, 2026 at 05:16:49PM -0400, Cen Zhang (Microsoft) wrote:
> Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied
> MTU values but only enforce a minimum bound, not a maximum.
I don't know the tipc code at all..
Can this be piped through netif_set_mtu()? It will call
dev_validate_mtu() which will validate the MTU against dev->min_mtu
and dev->max_mtu.
Andrew
^ permalink raw reply
* Re: [PATCH net] net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()
From: Hidayathulla Khan I @ 2026-07-10 16:20 UTC (permalink / raw)
To: Jagielski, Jedrzej, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com
Cc: horms@kernel.org, linux-s390@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
wintera@linux.ibm.com, twinkler@linux.ibm.com,
heiko.carstens@de.ibm.com, gor@linux.ibm.com,
agordeev@linux.ibm.com, borntraeger@linux.ibm.com,
svens@linux.ibm.com
In-Reply-To: <PH0PR11MB590247B1CA37A1E9A4B4FD79F0FD2@PH0PR11MB5902.namprd11.prod.outlook.com>
On 10/07/26 3:04 pm, Jagielski, Jedrzej wrote:
> From: Hidayath Khan <hidayath@linux.ibm.com>
> Sent: Thursday, July 9, 2026 9:18 PM
>
>> afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC.
>> If the allocation fails, nsk is NULL.
>>
>> The connection-refused path is entered when the listen state check
>> fails, the accept backlog is full, or nsk is NULL. The code
>> unconditionally calls iucv_sock_kill(nsk) in that path.
>>
>> iucv_sock_kill() does not accept a NULL socket pointer and immediately
>> dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL,
>> calling iucv_sock_kill(nsk) results in a NULL pointer dereference.
>>
>> Only call iucv_sock_kill() when a child socket was successfully
>> allocated.
>>
>> Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport")
>> Cc: stable@vger.kernel.org
>> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
>> Signed-off-by: Hidayath Khan <hidayath@linux.ibm.com>
>> ---
>> net/iucv/af_iucv.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
>> index fed240b453bd..f5b1ec44b6ae 100644
>> --- a/net/iucv/af_iucv.c
>> +++ b/net/iucv/af_iucv.c
>> @@ -1872,7 +1872,8 @@ static int afiucv_hs_callback_syn(struct sock *sk, struct sk_buff *skb)
>> afiucv_swap_src_dest(skb);
>> trans_hdr->flags = AF_IUCV_FLAG_SYN | AF_IUCV_FLAG_FIN;
>> err = dev_queue_xmit(skb);
>> - iucv_sock_kill(nsk);
>> + if (nsk)
> Hi Hidayath
>
> why not to move this check into iucv_sock_kill()?
> would prevent from potential similar issues in the future
Hi Jedrzej,
Every other call to iucv_sock_kill() passes a non-NULL socket by
construction.
If iucv_sock_kill() silently accepted NULL, a future caller wrongly
passing NULL would go unnoticed instead of being caught.
>
>> + iucv_sock_kill(nsk);
>> bh_unlock_sock(sk);
>> goto out;
>> }
>>
>> base-commit: 262b2eac463d880a664cf92af1107b4f9d84ad37
>> --
>> 2.52.0
>
>
^ permalink raw reply
* Re: [PATCH net v3] mptcp: only set DATA_FIN when a mapping is present
From: Matthieu Baerts @ 2026-07-10 16:19 UTC (permalink / raw)
To: Michael Bommarito, Mat Martineau
Cc: Geliang Tang, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Gang Yan, mptcp, netdev, linux-kernel
In-Reply-To: <20260709191925.2811195-1-michael.bommarito@gmail.com>
Hi Michael,
On 09/07/2026 21:19, Michael Bommarito wrote:
> mptcp_get_options() clears only the status group of struct
> mptcp_options_received; data_seq, subflow_seq and data_len are filled in
> by mptcp_parse_option() exclusively inside the DSS mapping block, which
> runs only when the DSS M (mapping present) bit is set.
>
> A peer can send a DSS option with the DATA_FIN flag set but the mapping
> bit clear. The parser then records mp_opt->data_fin while leaving
> data_len and data_seq uninitialized. For a zero-length segment
> mptcp_incoming_options() evaluates
>
> if (mp_opt.data_fin && mp_opt.data_len == 1 &&
> mptcp_update_rcv_data_fin(msk, mp_opt.data_seq, mp_opt.dsn64))
>
> which reads the uninitialized data_len and data_seq; KMSAN reports an
> uninit-value in mptcp_incoming_options(). The stale data_seq can also be
> fed into the receive-side DATA_FIN sequence tracking.
>
> Record the DATA_FIN flag only when the DSS option carries a mapping, so
> data_fin is never set without data_seq and data_len also being present.
> data_fin is part of the status group that mptcp_get_options() clears up
> front, so on the no-map path it stays zero and the zero-length DATA_FIN
> branch is simply skipped. A DATA_FIN is always transmitted together with
> a mapping (mptcp_write_data_fin() sets use_map along with data_seq and
> data_len), so legitimate DATA_FIN handling is unaffected.
>
> Move the pr_debug() that logs the parsed DSS flags below the mapping
> block, so it reports the final data_fin value instead of the stale one
> it would otherwise print before the assignment.
Thank you for the v3, it looks good to me:
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
I tried to reproduce it on my side using packetdrill-mptcp [1], but I
was not able to test with KMSAN: my kernel boot, but is stuck when KMSAN
is enabled... By chance, if you can try this reproducer on your side,
with and without your patched kernel, that would be great :)
[1] https://github.com/multipath-tcp/packetdrill/pull/203
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply
* Re: [PATCH net-next 1/2] dt-bindings: net: dsa: mediatek,mt7530: add econet,en7528-switch
From: Conor Dooley @ 2026-07-10 16:18 UTC (permalink / raw)
To: Ahmed Naseef
Cc: netdev, Arınç ÜNAL, Chester A. Unal,
David S. Miller, Andrew Lunn, AngeloGioacchino Del Regno,
Conor Dooley, DENG Qingfang, Daniel Golle, Eric Dumazet,
Jakub Kicinski, Krzysztof Kozlowski, Landen Chao,
Matthias Brugger, Paolo Abeni, Rob Herring, Russell King,
Sean Wang, Vladimir Oltean, devicetree, linux-arm-kernel,
linux-kernel, linux-mediatek
In-Reply-To: <68e85666b6dfedab719aaa388450eb86312eccd0.1783680864.git.naseefkm@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]
On Fri, Jul 10, 2026 at 02:54:23PM +0400, Ahmed Naseef wrote:
> The EcoNet EN7528 MIPS SoC integrates an MT7530 Gigabit switch,
> memory-mapped in the SoC register space like the built-in switches of
> the MediaTek MT7988 and Airoha EN7581/AN7583 SoCs. Its four user ports
> are connected to integrated Gigabit PHYs and its CPU port is connected
> internally to the SoC Ethernet MAC.
Please note what actually makes this different from the other devices
such that it cannot use a fallback. It's not clear from this description
if the described features are shared with other devices or unique.
pw-bot: changes-requested
Thanks,
Conor.
>
> Add the econet,en7528-switch compatible, with the same constraints as
> the other built-in switches.
>
> Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
> ---
> .../devicetree/bindings/net/dsa/mediatek,mt7530.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
> index 815a90808901..90b3582b7619 100644
> --- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
> +++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
> @@ -100,6 +100,10 @@ properties:
> Built-in switch of the Airoha AN7583 SoC
> const: airoha,an7583-switch
>
> + - description:
> + Built-in switch of the EcoNet EN7528 SoC
> + const: econet,en7528-switch
> +
> reg:
> maxItems: 1
>
> @@ -318,6 +322,7 @@ allOf:
> - mediatek,mt7988-switch
> - airoha,en7581-switch
> - airoha,an7583-switch
> + - econet,en7528-switch
> then:
> $ref: "#/$defs/builtin-dsa-port"
> properties:
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH bpf] bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch()
From: Kuniyuki Iwashima @ 2026-07-10 16:17 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jose Fernandez (Anthropic), Eric Dumazet, Neal Cardwell,
David S. Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Andrii Nakryiko, Yonghong Song, Martin KaFai Lau, Jiayuan Chen,
Emil Tsalapatis, netdev, linux-kernel, bpf, Ben Cressey
In-Reply-To: <19e8e6f9-0d4c-4ae4-b519-603420619363@iogearbox.net>
On Fri, Jul 10, 2026 at 7:32 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> Hi Jose,
>
> On 7/10/26 3:44 PM, Jose Fernandez (Anthropic) wrote:
> > Hi all,
> >
> > Gentle ping. This has Reviewed-by from Jiayuan Chen and Emil Tsalapatis
> > and no outstanding objections since Jun 29. Is anything else needed for
> > bpf-fixes?
> >
> > On the automated review's flag about the pre-existing double-put on the
> > bpf_iter_tcp_realloc_batch() failure path (cur_sk/end_sk not reset
> > before seq_stop, so cookies can be re-put as pointers): agreed it is
> > real, and it predates this change. As Jiayuan noted, it is a separate,
> > pre-existing issue best addressed on its own; I kept this patch minimal
> > for stable.
>
> Given TCP, it would be good to still get an Ack from Kuniyuki or Eric and
> then we can ship it. Are you planning to also follow-up with the other pre-
> existing issue finding?
Oh sorry, somehow I missed this patch. Will look into it today.
Thanks !
^ permalink raw reply
* Re: [PATCH v2 net-next 13/14] ipvlan: Protect ipvl_port.ipvlans with mutex.
From: Kuniyuki Iwashima @ 2026-07-10 16:15 UTC (permalink / raw)
To: Paolo Abeni
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Andrew Lunn,
Simon Horman, Kuniyuki Iwashima, netdev
In-Reply-To: <71f1aba1-78b6-4e7b-8dc9-092b50402e07@redhat.com>
On Fri, Jul 10, 2026 at 4:08 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On 7/3/26 2:09 AM, Kuniyuki Iwashima wrote:
> > @@ -800,9 +831,15 @@ static int ipvlan_device_event(struct notifier_block *unused,
> > if (dev->reg_state != NETREG_UNREGISTERING)
> > break;
> >
> > - list_for_each_entry_safe(ipvlan, next, &port->ipvlans, pnode)
> > - ipvlan->dev->rtnl_link_ops->dellink(ipvlan->dev,
> > - &lst_kill);
> > + list_for_each_entry_safe(ipvlan, next, &port->ipvlans, pnode) {
> > +#if IS_ENABLED(CONFIG_IPVTAP)
> > + if (ipvlan->dev->rtnl_link_ops != &ipvlan_link_ops)
> > + __ipvtap_dellink_ptr(ipvlan->dev, &lst_kill);
> > + else
> > +#endif
> > + __ipvlan_link_delete(ipvlan->dev, &lst_kill);
>
> I'm not sure if it's worthy a repost, but what about adding a
> link_delete_unlocked() cb to `struct ipvl_dev *`? IMHO should make this
> code more straight forward.
Since port is allocated in ndo_init(), ipvtap needs to wrap it
and overwrite port->ops everytime for one time (or at ->newlink),
but I don't have strong opinion here.
It would be nicer if I could follow up since this series gets 5-days
penalty on Suie due to too many Sashiko false-positive, get_net(),
and a build warning due to xchg() for veth, and we will likely lose
context next week :)
^ 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