* Re: [PATCH net] ipv6: ndisc: fix NULL deref in accept_untracked_na()
From: Jiayuan Chen @ 2026-06-17 8:32 UTC (permalink / raw)
To: Weiming Shi, David S . Miller, David Ahern, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, netdev, linux-kernel, Xiang Mei
In-Reply-To: <20260617065512.2529757-2-bestswngs@gmail.com>
On 6/17/26 2:55 PM, Weiming Shi wrote:
> accept_untracked_na() re-fetches the inet6_dev with __in6_dev_get(dev)
> and dereferences idev->cnf.accept_untracked_na without a NULL check,
Does ipv6_rpl_srh_rcv have same problem?
^ permalink raw reply
* Re: [REGRESSION 6.16] r8169 RTL8168h/8111h fails to probe — "Unable to change power state from D3cold to D0" — bisected to 4d4c10f763d7
From: Thorsten Leemhuis @ 2026-06-17 8:32 UTC (permalink / raw)
To: Josh Perry, mario.limonciello, bhelgaas
Cc: hkallweit1, nic_swsd, rafael, linux-pci, netdev, regressions
In-Reply-To: <d4aaa5e8-7366-461c-94b1-ccf3631c8bf9@6bit.com>
On 6/12/26 03:07, Josh Perry wrote:
> #regzbot introduced: 4d4c10f763d7
>
> Since v6.16 one of two onboard RTL8168h/8111h NICs on this board fails
> to probe on boot; the device drops to D3cold and the driver can't bring
> it back:
FWIW, that commit is 4d4c10f763d780 ("PCI: Explicitly put devices into
D0 when initializing") [v6.16-rc1] from Mario, who is already CCed, but
looks like might be on holiday or something due to inactivity on the
lists in the recent days. So it might take a few days before this moves on.
Josh, this is not my area of expertise, but there are two things I guess
might be helpful:
* retry with 7.1
* upload "dmesg" and "sudo lspci -vvv" output from working and broken
kernels somewhere (like bugzilla.kernel.org).
Ciao, Thorsten
> r8169 0000:02:00.0 eth0: RTL8168h/8111h, 00:2b:67:48:40:01, XID 541,
> IRQ 137
> r8169 0000:04:00.0: Unable to change power state from D3cold to D0,
> device inaccessible
> r8169 0000:04:00.0: Mem-Wr-Inval unavailable
> r8169 0000:04:00.0: error -EIO: PCI read failed
> r8169 0000:04:00.0: probe with driver r8169 failed with error -5
>
> The board has two identical RTL8168h NICs (both XID 541): 0000:02:00.0
> and 0000:04:00.0. Only 04:00.0 fails — its sibling 02:00.0, on a
> different root port, probes and works normally on the very same kernel
> and boot. The failing NIC then does not appear (no enp4s0), taking the
> machine's WAN offline. This strongly suggests the problem is port/
> topology-specific rather than device- or driver-specific: the upstream
> port behind 04:00.0 is placed in D3cold and the endpoint cannot be
> resumed to D0.
>
> Hardware: RTL8168h/8111h, XID 541, PCI 04:00.0 (onboard 1GbE).
> Platform: Lenovo ThinkCentre M90n-1 (11AHS0B200), BIOS M2AKT49A
> (2026-03-25, latest available). Firmware is current, so this is not a
> platform-firmware issue.
>
> Bisection: v6.15 good, v6.16 bad (verified by booting both). I then
> reverted 4d4c10f763d7 ("PCI: Explicitly put devices into D0 when
> initializing") together with its follow-up 907a7a2e5bf4 ("PCI/PM: Set up
> runtime PM even for devices without PCI PM") on top of 6.16.7: the NIC
> probes and links at 1Gbps/Full normally, with no workaround:
>
> r8169 0000:04:00.0 eth1: RTL8168h/8111h, 00:2b:67:48:40:02, XID 541,
> IRQ 138
> r8169 0000:04:00.0 enp4s0: Link is Up - 1Gbps/Full - flow control rx/tx
>
> Workaround: booting an unmodified v6.16+ kernel with pcie_port_pm=off
> also restores the NIC, which is consistent with the upstream port being
> placed in D3cold and the device failing to resume to D0 after the
> explicit-D0 init change.
>
> The follow-up 907a7a2e5bf4 does not fix this resume case: v6.18.33 is
> still affected (retested today on current firmware).
>
> Happy to test patches or provide full dmesg / lspci.
>
^ permalink raw reply
* Re: [PATCH net-next v6 1/2] dinghai: add ZTE network driver support
From: Uwe Kleine-König @ 2026-06-17 8:30 UTC (permalink / raw)
To: han.junyang
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms, linux-kernel,
netdev, ran.ming, han.chengfei, zhang.yanze
In-Reply-To: <20260616213057452I2KLm3mVgWYl_SUTy_YYS@zte.com.cn>
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
Hello,
On Tue, Jun 16, 2026 at 09:30:57PM +0800, han.junyang@zte.com.cn wrote:
> +static const struct pci_device_id dh_pf_pci_table[] = {
> + { PCI_DEVICE(ZXDH_PF_VENDOR_ID, ZXDH_PF_DEVICE_ID), 0 },
> + { PCI_DEVICE(ZXDH_PF_VENDOR_ID, ZXDH_VF_DEVICE_ID), 0 },
> + { 0, }
> +};
Please make this:
+static const struct pci_device_id dh_pf_pci_table[] = {
+ { PCI_DEVICE(ZXDH_PF_VENDOR_ID, ZXDH_PF_DEVICE_ID) },
+ { PCI_DEVICE(ZXDH_PF_VENDOR_ID, ZXDH_VF_DEVICE_ID) },
+ { }
+};
(because the assignment to .driver_data is superflous and initializing
it using a list expression is in the way for one of my patch quests).
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 5.10.y] net: add missing ns_capable check for peer netns
From: Maximilian Heyne @ 2026-06-17 8:27 UTC (permalink / raw)
To: stable
Cc: Maximilian Heyne, Wolfgang Grandegger, Marc Kleine-Budde,
David S. Miller, Jakub Kicinski, Eric W. Biederman, Eric Dumazet,
linux-can, netdev, linux-kernel
The upstream commit 7b735ef81286 ("rtnetlink: add missing
netlink_ns_capable() check for peer netns") doesn't apply on older
stable kernels due to refactoring. Therefore, this patch is an attempt
to implement the same capability check just directly in the respective
interface types.
Approximate the netlink_ns_capable check with an ns_capable check. As
the newlink operation is synchronous this should result in the same
behavior.
Without this commit, for example, the following command creating a veth
device in network namespace of pid 1 succeeds:
$ unshare -U -r -n -- bash -c '
ip link add veth0 type veth peer name foobar netns 1
sleep 60' &
$ ip link show foobar
13: foobar@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 96:09:69:92:92:cc brd ff:ff:ff:ff:ff:ff link-netnsid 1
With this patch, it's returning -EPERM.
This fixes CVE-2026-31692
Cc: stable@vger.kernel.org
Fixes: 81adee47dfb6 ("net: Support specifying the network namespace upon device creation.")
Assisted-by: Kiro:claude
Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
---
drivers/net/can/vxcan.c | 5 +++++
drivers/net/veth.c | 5 +++++
2 files changed, 10 insertions(+)
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index 1bfede407270d..05fcbfacc3433 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -198,6 +198,11 @@ static int vxcan_newlink(struct net *net, struct net_device *dev,
if (IS_ERR(peer_net))
return PTR_ERR(peer_net);
+ if (!ns_capable(peer_net->user_ns, CAP_NET_ADMIN)) {
+ put_net(peer_net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(peer_net, ifname, name_assign_type,
&vxcan_link_ops, tbp, extack);
if (IS_ERR(peer)) {
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 743716ebebdb9..bda3add65c76e 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -1341,6 +1341,11 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
if (IS_ERR(net))
return PTR_ERR(net);
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+ put_net(net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(net, ifname, name_assign_type,
&veth_link_ops, tbp, extack);
if (IS_ERR(peer)) {
--
2.50.1
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply related
* [PATCH 5.15.y] net: add missing ns_capable check for peer netns
From: Maximilian Heyne @ 2026-06-17 8:27 UTC (permalink / raw)
To: stable
Cc: Maximilian Heyne, Wolfgang Grandegger, Marc Kleine-Budde,
David S. Miller, Jakub Kicinski, Eric Dumazet, Eric W. Biederman,
linux-can, netdev, linux-kernel
The upstream commit 7b735ef81286 ("rtnetlink: add missing
netlink_ns_capable() check for peer netns") doesn't apply on older
stable kernels due to refactoring. Therefore, this patch is an attempt
to implement the same capability check just directly in the respective
interface types.
Approximate the netlink_ns_capable check with an ns_capable check. As
the newlink operation is synchronous this should result in the same
behavior.
Without this commit, for example, the following command creating a veth
device in network namespace of pid 1 succeeds:
$ unshare -U -r -n -- bash -c '
ip link add veth0 type veth peer name foobar netns 1
sleep 60' &
$ ip link show foobar
13: foobar@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 96:09:69:92:92:cc brd ff:ff:ff:ff:ff:ff link-netnsid 1
With this patch, it's returning -EPERM.
This fixes CVE-2026-31692
Cc: stable@vger.kernel.org
Fixes: 81adee47dfb6 ("net: Support specifying the network namespace upon device creation.")
Assisted-by: Kiro:claude
Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
---
drivers/net/can/vxcan.c | 5 +++++
drivers/net/veth.c | 5 +++++
2 files changed, 10 insertions(+)
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index afd9060c5421c..8a61011fdaeef 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -198,6 +198,11 @@ static int vxcan_newlink(struct net *net, struct net_device *dev,
if (IS_ERR(peer_net))
return PTR_ERR(peer_net);
+ if (!ns_capable(peer_net->user_ns, CAP_NET_ADMIN)) {
+ put_net(peer_net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(peer_net, ifname, name_assign_type,
&vxcan_link_ops, tbp, extack);
if (IS_ERR(peer)) {
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index cfacf8965bc59..c644d59d70900 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -1664,6 +1664,11 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
if (IS_ERR(net))
return PTR_ERR(net);
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+ put_net(net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(net, ifname, name_assign_type,
&veth_link_ops, tbp, extack);
if (IS_ERR(peer)) {
--
2.50.1
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply related
* [PATCH 6.1.y] net: add missing ns_capable check for peer netns
From: Maximilian Heyne @ 2026-06-17 8:27 UTC (permalink / raw)
To: stable
Cc: Maximilian Heyne, Wolfgang Grandegger, Marc Kleine-Budde,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Eric W. Biederman, linux-can, netdev, linux-kernel
The upstream commit 7b735ef81286 ("rtnetlink: add missing
netlink_ns_capable() check for peer netns") doesn't apply on older
stable kernels due to refactoring. Therefore, this patch is an attempt
to implement the same capability check just directly in the respective
interface types.
Approximate the netlink_ns_capable check with an ns_capable check. As
the newlink operation is synchronous this should result in the same
behavior.
Without this commit, for example, the following command creating a veth
device in network namespace of pid 1 succeeds:
$ unshare -U -r -n -- bash -c '
ip link add veth0 type veth peer name foobar netns 1
sleep 60' &
$ ip link show foobar
13: foobar@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 96:09:69:92:92:cc brd ff:ff:ff:ff:ff:ff link-netnsid 1
With this patch, it's returning -EPERM.
This fixes CVE-2026-31692
Cc: stable@vger.kernel.org
Fixes: 81adee47dfb6 ("net: Support specifying the network namespace upon device creation.")
Assisted-by: Kiro:claude
Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
---
drivers/net/can/vxcan.c | 5 +++++
drivers/net/veth.c | 5 +++++
2 files changed, 10 insertions(+)
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index 98c669ad51414..da4affff65476 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -211,6 +211,11 @@ static int vxcan_newlink(struct net *net, struct net_device *dev,
if (IS_ERR(peer_net))
return PTR_ERR(peer_net);
+ if (!ns_capable(peer_net->user_ns, CAP_NET_ADMIN)) {
+ put_net(peer_net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(peer_net, ifname, name_assign_type,
&vxcan_link_ops, tbp, extack);
if (IS_ERR(peer)) {
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index e1e8c825483aa..dac8cc5a79f5a 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -1707,6 +1707,11 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
if (IS_ERR(net))
return PTR_ERR(net);
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+ put_net(net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(net, ifname, name_assign_type,
&veth_link_ops, tbp, extack);
if (IS_ERR(peer)) {
--
2.50.1
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply related
* [PATCH 6.6.y] net: add missing ns_capable check for peer netns
From: Maximilian Heyne @ 2026-06-17 8:26 UTC (permalink / raw)
To: stable
Cc: Maximilian Heyne, Wolfgang Grandegger, Marc Kleine-Budde,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Eric W. Biederman, linux-can, netdev, linux-kernel
The upstream commit 7b735ef81286 ("rtnetlink: add missing
netlink_ns_capable() check for peer netns") doesn't apply on older
stable kernels due to refactoring. Therefore, this patch is an attempt
to implement the same capability check just directly in the respective
interface types.
Approximate the netlink_ns_capable check with an ns_capable check. As
the newlink operation is synchronous this should result in the same
behavior.
Without this commit, for example, the following command creating a veth
device in network namespace of pid 1 succeeds:
$ unshare -U -r -n -- bash -c '
ip link add veth0 type veth peer name foobar netns 1
sleep 60' &
$ ip link show foobar
13: foobar@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 96:09:69:92:92:cc brd ff:ff:ff:ff:ff:ff link-netnsid 1
With this patch, it's returning -EPERM.
This fixes CVE-2026-31692
Cc: stable@vger.kernel.org
Fixes: 81adee47dfb6 ("net: Support specifying the network namespace upon device creation.")
Assisted-by: Kiro:claude
Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
---
drivers/net/can/vxcan.c | 5 +++++
drivers/net/veth.c | 5 +++++
2 files changed, 10 insertions(+)
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index 98c669ad51414..da4affff65476 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -211,6 +211,11 @@ static int vxcan_newlink(struct net *net, struct net_device *dev,
if (IS_ERR(peer_net))
return PTR_ERR(peer_net);
+ if (!ns_capable(peer_net->user_ns, CAP_NET_ADMIN)) {
+ put_net(peer_net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(peer_net, ifname, name_assign_type,
&vxcan_link_ops, tbp, extack);
if (IS_ERR(peer)) {
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 2b3b0beb55c88..ba4ca6c6bc9d8 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -1857,6 +1857,11 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
if (IS_ERR(net))
return PTR_ERR(net);
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+ put_net(net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(net, ifname, name_assign_type,
&veth_link_ops, tbp, extack);
if (IS_ERR(peer)) {
--
2.50.1
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply related
* [PATCH 6.12.y] net: add missing ns_capable check for peer netns
From: Maximilian Heyne @ 2026-06-17 8:25 UTC (permalink / raw)
To: stable
Cc: Maximilian Heyne, Marc Kleine-Budde, Vincent Mailhol, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Daniel Borkmann, Nikolay Aleksandrov, Eric W. Biederman,
linux-can, netdev, linux-kernel, bpf
The upstream commit 7b735ef81286 ("rtnetlink: add missing
netlink_ns_capable() check for peer netns") doesn't apply on older
stable kernels due to refactoring. Therefore, this patch is an attempt
to implement the same capability check just directly in the respective
interface types.
Approximate the netlink_ns_capable check with an ns_capable check. As
the newlink operation is synchronous this should result in the same
behavior.
Without this commit, for example, the following command creating a veth
device in network namespace of pid 1 succeeds:
$ unshare -U -r -n -- bash -c '
ip link add veth0 type veth peer name foobar netns 1
sleep 60' &
$ ip link show foobar
13: foobar@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 96:09:69:92:92:cc brd ff:ff:ff:ff:ff:ff link-netnsid 1
With this patch, it's returning -EPERM.
This fixes CVE-2026-31692
Cc: stable@vger.kernel.org
Fixes: 81adee47dfb6 ("net: Support specifying the network namespace upon device creation.")
Assisted-by: Kiro:claude
Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
---
drivers/net/can/vxcan.c | 5 +++++
drivers/net/netkit.c | 5 +++++
drivers/net/veth.c | 5 +++++
3 files changed, 15 insertions(+)
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index 9e1b7d41005f8..851c93bf0b310 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -211,6 +211,11 @@ static int vxcan_newlink(struct net *net, struct net_device *dev,
if (IS_ERR(peer_net))
return PTR_ERR(peer_net);
+ if (!ns_capable(peer_net->user_ns, CAP_NET_ADMIN)) {
+ put_net(peer_net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(peer_net, ifname, name_assign_type,
&vxcan_link_ops, tbp, extack);
if (IS_ERR(peer)) {
diff --git a/drivers/net/netkit.c b/drivers/net/netkit.c
index fba2c734f0ec7..e0c42fa0c835c 100644
--- a/drivers/net/netkit.c
+++ b/drivers/net/netkit.c
@@ -413,6 +413,11 @@ static int netkit_new_link(struct net *src_net, struct net_device *dev,
if (IS_ERR(net))
return PTR_ERR(net);
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+ put_net(net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(net, ifname, ifname_assign_type,
&netkit_link_ops, tbp, extack);
if (IS_ERR(peer)) {
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 77e4b0d1ca557..6ffde7ee2119d 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -1854,6 +1854,11 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
if (IS_ERR(net))
return PTR_ERR(net);
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+ put_net(net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(net, ifname, name_assign_type,
&veth_link_ops, tbp, extack);
if (IS_ERR(peer)) {
--
2.50.1
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply related
* Re: [PATCH net v3] net: pch_gbe: handle TX skb allocation failure
From: Simon Horman @ 2026-06-17 8:24 UTC (permalink / raw)
To: Ruoyu Wang
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Masayuki Ohtake, netdev, linux-kernel
In-Reply-To: <20260615125043.3537046-1-ruoyuw560@gmail.com>
On Mon, Jun 15, 2026 at 08:50:42PM +0800, Ruoyu Wang wrote:
> pch_gbe_alloc_tx_buffers() allocates an skb for each TX descriptor and
> then passes the returned pointer to skb_reserve(). If netdev_alloc_skb()
> fails, skb_reserve() dereferences NULL.
>
> Make pch_gbe_alloc_tx_buffers() return an error when an skb allocation
> fails. On failure, let pch_gbe_alloc_tx_buffers() clean the partially
> allocated TX ring before returning the error. While bringing the device
> up, release the RX buffer pool through a shared cleanup helper before
> unwinding the IRQ setup.
>
> Fixes: 77555ee72282 ("net: Add Gigabit Ethernet driver of Topcliff PCH")
> Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
> ---
> Changes in v3:
> - Move the partial TX ring cleanup into pch_gbe_alloc_tx_buffers(), as
> suggested by Simon Horman.
>
> Changes in v2:
> - Add the kernel-doc return value description for
> pch_gbe_alloc_tx_buffers().
Thanks for the updates.
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH v2] ice: retry reading NVM if admin queue returns EBUSY
From: Robert Malz @ 2026-06-17 8:11 UTC (permalink / raw)
To: Loktionov, Aleksandr
Cc: Nguyen, Anthony L, Kitszel, Przemyslaw,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org
In-Reply-To: <IA3PR11MB8986729EE79F3F3FBAAC68C9E5E42@IA3PR11MB8986.namprd11.prod.outlook.com>
(resend)
Hey Aleksandr,
Thanks for taking a look at this.
exit loop, just like in OOT, happens during:
> if (hw->adminq.sq_last_status != LIBIE_AQ_RC_EBUSY ||
> retry_cnt > ICE_SQ_SEND_MAX_EXECUTE)
> break;
And by the way, I have v3 ready, which I plan to send 24 hours after
the initial submission, it doesn't change any code but I want to keep
the netdev bots happy.
Thanks,
Robert
On Wed, Jun 17, 2026 at 9:47 AM Loktionov, Aleksandr
<aleksandr.loktionov@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> > Of Robert Malz via Intel-wired-lan
> > Sent: Wednesday, June 17, 2026 12:08 AM
> > To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> > Przemyslaw <przemyslaw.kitszel@intel.com>
> > Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org
> > Subject: [Intel-wired-lan] [PATCH v2] ice: retry reading NVM if
> > admin queue returns EBUSY
> >
> > When the admin queue command to read NVM returns EBUSY, the driver
> > currently treats it as a fatal error and aborts the entire read
> > operation. This can cause spurious NVM read failures during periods
> > of high firmware activity.
> >
> > Add retry logic to ice_read_flat_nvm() that handles EBUSY responses
> > from the admin queue. When an EBUSY error is encountered, release
> > the NVM resource lock, wait for ICE_SQ_SEND_DELAY_TIME_MS, re-
> > acquire it, and retry the failed read. The retry is attempted up to
> > ICE_SQ_SEND_MAX_EXECUTE times before giving up.
> >
> > Code was extracted from OOT ice driver 1.15.4 release. Additional
> > change was made to reset last_cmd in case of retry to make sure that
> > all commands are retried properly.
> >
> > Fixes: e94509906d6b ("ice: create function to read a section of the
> > NVM and Shadow RAM")
> > Signed-off-by: Robert Malz <robert.malz@canonical.com>
> > ---
> > Changes in v2:
> > - change ICE_AQ_RC_EBUSY -> LIBIE_AQ_RC_EBUSY
> >
> > drivers/net/ethernet/intel/ice/ice_nvm.c | 25 +++++++++++++++++++--
> > ---
> > 1 file changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/ice/ice_nvm.c
> > b/drivers/net/ethernet/intel/ice/ice_nvm.c
> > index 7e187a804dfa..b3120605d66f 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_nvm.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_nvm.c
> > @@ -67,6 +67,7 @@ ice_read_flat_nvm(struct ice_hw *hw, u32 offset,
> > u32 *length, u8 *data, {
> > u32 inlen = *length;
> > u32 bytes_read = 0;
> > + int retry_cnt = 0;
> > bool last_cmd;
> > int status;
> >
> > @@ -96,11 +97,25 @@ ice_read_flat_nvm(struct ice_hw *hw, u32 offset,
> > u32 *length, u8 *data,
> > offset, read_size,
> > data + bytes_read, last_cmd,
> > read_shadow_ram, NULL);
> > - if (status)
> > - break;
> > -
> > - bytes_read += read_size;
> > - offset += read_size;
> > + if (status) {
> > + if (hw->adminq.sq_last_status !=
> > LIBIE_AQ_RC_EBUSY ||
> > + retry_cnt > ICE_SQ_SEND_MAX_EXECUTE)
> > + break;
> > + ice_debug(hw, ICE_DBG_NVM,
> > + "NVM read EBUSY error, retry %d\n",
> > + retry_cnt + 1);
> > + last_cmd = false;
> > + ice_release_nvm(hw);
> > + msleep(ICE_SQ_SEND_DELAY_TIME_MS);
> > + status = ice_acquire_nvm(hw, ICE_RES_READ);
> > + if (status)
> > + break;
> > + retry_cnt++;
> It looks like you added the retry_cnt increment but you didn't add it into the loop exit condition.
>
>
> > + } else {
> > + bytes_read += read_size;
> > + offset += read_size;
> > + retry_cnt = 0;
> > + }
> > } while (!last_cmd);
> >
> > *length = bytes_read;
> > --
> > 2.34.1
>
^ permalink raw reply
* Re: [PATCH] e1000: Remove redundant else after return
From: Lovekesh Solanki @ 2026-06-17 7:58 UTC (permalink / raw)
To: andrew
Cc: andrew+netdev, anthony.l.nguyen, davem, edumazet, kuba,
lovekeshsolanki00, netdev, pabeni, przemyslaw.kitszel
In-Reply-To: <ead7bfc9-3978-4442-9cd1-23c2182b36b3@lunn.ch>
Hi Andrew,
I read the documentation you linked and understand simple standalone
cleanups are discouraged.
Thanks for the review, I will drop this patch.
Regards,
Lovekesh
^ permalink raw reply
* [PATCH net v4] tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done
From: Doruk Tan Ozturk @ 2026-06-17 7:58 UTC (permalink / raw)
To: jmaloy
Cc: davem, edumazet, kuba, pabeni, horms, aleksander.lobakin,
tung.quang.nguyen, tipc-discussion, netdev, linux-kernel,
Doruk Tan Ozturk, stable
tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to
crypto_aead_decrypt(req) without taking a reference on the netns, unlike
the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously
(e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs
tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the
meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the
per-netns tipc_crypto, and the completion then reads it:
tipc_aead_decrypt_done() dereferences aead->crypto->stats and
aead->crypto->net, and tipc_crypto_rcv_complete() dereferences
aead->crypto->aead[] and the node table -- reading freed memory.
Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO):
BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999)
Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51
Workqueue: events_unbound
Call Trace:
tipc_aead_decrypt_done (net/tipc/crypto.c:999)
process_one_work (kernel/workqueue.c:3314)
worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
Allocated by task 169:
__kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415)
tipc_crypto_start (net/tipc/crypto.c:1502)
tipc_init_net (net/tipc/core.c:72)
ops_init (net/core/net_namespace.c:137)
setup_net (net/core/net_namespace.c:446)
copy_net_ns (net/core/net_namespace.c:579)
create_new_namespaces (kernel/nsproxy.c:132)
__x64_sys_unshare (kernel/fork.c:3316)
do_syscall_64 (arch/x86/entry/syscall_64.c:63)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
Freed by task 8:
kfree (mm/slub.c:6566)
tipc_exit_net (net/tipc/core.c:119)
cleanup_net (net/core/net_namespace.c:704)
process_one_work (kernel/workqueue.c:3314)
kthread (kernel/kthread.c:436)
This is the same class of bug that commit e279024617134 ("net/tipc: fix
slab-use-after-free Read in tipc_aead_encrypt_done") fixed for the encrypt
side. The encrypt path takes maybe_get_net(aead->crypto->net) before
crypto_aead_encrypt() and drops it with put_net() on the synchronous
return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY
return keeps the reference for the async callback to release. The decrypt
path was left without the equivalent guard.
Mirror the encrypt-side fix on the decrypt path: take a net reference
before crypto_aead_decrypt() (failing with -ENODEV and the matching
bearer put if it cannot be acquired), keep it across the
-EINPROGRESS/-EBUSY async return, and drop it with put_net() on the
synchronous success/error return and at the end of
tipc_aead_decrypt_done().
Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is
flooded with crafted encrypted frames from an unknown peer (driving the
cluster-key decrypt path) while the bearer's netns is repeatedly torn
down. The completion must run asynchronously to outlive
tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts
synchronously, so the async path was exercised via cryptd offload. The
unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the
unpatched upstream path; tipc_aead_decrypt() still lacks
maybe_get_net(aead->crypto->net), so the completion can outlive the free
on any config where crypto_aead_decrypt() goes async.
Found by 0sec automated security-research tooling (https://0sec.ai).
Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
Cc: stable@vger.kernel.org
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech>
---
v4:
- Use the net parameter for maybe_get_net()/put_net() instead of
dereferencing aead->crypto->net, which is the per-netns structure at
risk during teardown (per the automated review forwarded by Simon
Horman). net == aead->crypto->net here; no functional change.
v3:
- Rewrite the changelog with the decoded stack trace and frame the
reproduction on the current tree (v7.1-rc7); drop the v6.12.92
references (Tung Quang Nguyen).
v2:
- Add Cc: stable@vger.kernel.org and Alexander Lobakin's Reviewed-by.
No functional change.
net/tipc/crypto.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
index 6d3b6b89b1d1..16f1ed1f6b1b 100644
--- a/net/tipc/crypto.c
+++ b/net/tipc/crypto.c
@@ -941,12 +941,20 @@ static int tipc_aead_decrypt(struct net *net, struct tipc_aead *aead,
goto exit;
}
+ /* Get net to avoid freed tipc_crypto when delete namespace */
+ if (!maybe_get_net(net)) {
+ tipc_bearer_put(b);
+ rc = -ENODEV;
+ goto exit;
+ }
+
/* Now, do decrypt */
rc = crypto_aead_decrypt(req);
if (rc == -EINPROGRESS || rc == -EBUSY)
return rc;
tipc_bearer_put(b);
+ put_net(net);
exit:
kfree(ctx);
@@ -984,6 +992,7 @@ static void tipc_aead_decrypt_done(void *data, int err)
}
tipc_bearer_put(b);
+ put_net(net);
}
static inline int tipc_ehdr_size(struct tipc_ehdr *ehdr)
--
2.43.0
^ permalink raw reply related
* RE: [Intel-wired-lan] [PATCH net v2] iavf: validate num_vsis in VIRTCHNL_OP_GET_VF_RESOURCES response
From: Romanowski, Rafal @ 2026-06-17 7:49 UTC (permalink / raw)
To: Simon Horman, Junrui Luo
Cc: Nguyen, Anthony L, Kitszel, Przemyslaw, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Mitch Williams, Greg Rose, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Yuhao Jiang,
stable@vger.kernel.org
In-Reply-To: <20260518185611.GF98116@horms.kernel.org>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Simon
> Horman
> Sent: Monday, May 18, 2026 8:56 PM
> To: Junrui Luo <moonafterrain@outlook.com>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Mitch Williams <mitch.a.williams@intel.com>; Greg Rose
> <gregory.v.rose@intel.com>; intel-wired-lan@lists.osuosl.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Yuhao Jiang
> <danisjiang@gmail.com>; stable@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH net v2] iavf: validate num_vsis in
> VIRTCHNL_OP_GET_VF_RESOURCES response
>
> On Thu, May 14, 2026 at 02:55:04PM +0800, Junrui Luo wrote:
> > The VF allocates a fixed-size buffer for IAVF_MAX_VF_VSI (3) VSI
> > entries when processing a VIRTCHNL_OP_GET_VF_RESOURCES response from
> > the PF. However, num_vsis from the PF response is used unchecked as
> > the loop bound when iterating over vsi_res[] in multiple functions.
> >
> > A PF sending num_vsis greater than IAVF_MAX_VF_VSI, or the received
> > message is shorter than num_vsis claims leads to out-of-bounds
> > accesses on the vsi_res[] array.
> >
> > Clamp num_vsis based on the actual bytes copied from the PF response.
> >
> > Fixes: 5eae00c57f5e ("i40evf: main driver core")
> > Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
> > ---
> > Changes in v2:
> > - Clamp num_vsis based on actual received message length instead of
> > IAVF_MAX_VF_VSI suggested by Przemek
> > - Link to v1:
> >
> https://lore.kernel.org/r/SYBPR01MB7881AF11C45AEDC0D4CA89C1AF062@SYB
> PR
> > 01MB7881.ausprd01.prod.outlook.com
>
> Reviewed-by: Simon Horman <horms@kernel.org>
>
> There is an AI-generated review of this patchset available on sashiko.dev.
> However, I believe that the issues raised there can be considered in the context of
> possible follow-up. I do not believe they should block progress of this patch.
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH v2] ice: retry reading NVM if admin queue returns EBUSY
From: Loktionov, Aleksandr @ 2026-06-17 7:47 UTC (permalink / raw)
To: Robert Malz, Nguyen, Anthony L, Kitszel, Przemyslaw
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org
In-Reply-To: <20260616220827.1647052-1-robert.malz@canonical.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Robert Malz via Intel-wired-lan
> Sent: Wednesday, June 17, 2026 12:08 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>
> Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH v2] ice: retry reading NVM if
> admin queue returns EBUSY
>
> When the admin queue command to read NVM returns EBUSY, the driver
> currently treats it as a fatal error and aborts the entire read
> operation. This can cause spurious NVM read failures during periods
> of high firmware activity.
>
> Add retry logic to ice_read_flat_nvm() that handles EBUSY responses
> from the admin queue. When an EBUSY error is encountered, release
> the NVM resource lock, wait for ICE_SQ_SEND_DELAY_TIME_MS, re-
> acquire it, and retry the failed read. The retry is attempted up to
> ICE_SQ_SEND_MAX_EXECUTE times before giving up.
>
> Code was extracted from OOT ice driver 1.15.4 release. Additional
> change was made to reset last_cmd in case of retry to make sure that
> all commands are retried properly.
>
> Fixes: e94509906d6b ("ice: create function to read a section of the
> NVM and Shadow RAM")
> Signed-off-by: Robert Malz <robert.malz@canonical.com>
> ---
> Changes in v2:
> - change ICE_AQ_RC_EBUSY -> LIBIE_AQ_RC_EBUSY
>
> drivers/net/ethernet/intel/ice/ice_nvm.c | 25 +++++++++++++++++++--
> ---
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_nvm.c
> b/drivers/net/ethernet/intel/ice/ice_nvm.c
> index 7e187a804dfa..b3120605d66f 100644
> --- a/drivers/net/ethernet/intel/ice/ice_nvm.c
> +++ b/drivers/net/ethernet/intel/ice/ice_nvm.c
> @@ -67,6 +67,7 @@ ice_read_flat_nvm(struct ice_hw *hw, u32 offset,
> u32 *length, u8 *data, {
> u32 inlen = *length;
> u32 bytes_read = 0;
> + int retry_cnt = 0;
> bool last_cmd;
> int status;
>
> @@ -96,11 +97,25 @@ ice_read_flat_nvm(struct ice_hw *hw, u32 offset,
> u32 *length, u8 *data,
> offset, read_size,
> data + bytes_read, last_cmd,
> read_shadow_ram, NULL);
> - if (status)
> - break;
> -
> - bytes_read += read_size;
> - offset += read_size;
> + if (status) {
> + if (hw->adminq.sq_last_status !=
> LIBIE_AQ_RC_EBUSY ||
> + retry_cnt > ICE_SQ_SEND_MAX_EXECUTE)
> + break;
> + ice_debug(hw, ICE_DBG_NVM,
> + "NVM read EBUSY error, retry %d\n",
> + retry_cnt + 1);
> + last_cmd = false;
> + ice_release_nvm(hw);
> + msleep(ICE_SQ_SEND_DELAY_TIME_MS);
> + status = ice_acquire_nvm(hw, ICE_RES_READ);
> + if (status)
> + break;
> + retry_cnt++;
It looks like you added the retry_cnt increment but you didn't add it into the loop exit condition.
> + } else {
> + bytes_read += read_size;
> + offset += read_size;
> + retry_cnt = 0;
> + }
> } while (!last_cmd);
>
> *length = bytes_read;
> --
> 2.34.1
^ permalink raw reply
* Re: [PATCH net] netpoll: run NAPI poll in softirq context to avoid rq->lock self-deadlock
From: John Ogness @ 2026-06-17 7:42 UTC (permalink / raw)
To: Breno Leitao, Sebastian Andrzej Siewior, pmladek
Cc: Jakub Kicinski, Petr Mladek, Sergey Senozhatsky, Peter Zijlstra,
Vlad Poenaru, Thomas Gleixner, netdev, David S . Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Clark Williams,
Steven Rostedt, linux-rt-devel, linux-kernel, stable,
Frederic Weisbecker, Ingo Molnar, Vincent Guittot,
Dietmar Eggemann, K Prateek Nayak
In-Reply-To: <ajF5S0uY-8F0jzoh@gmail.com>
On 2026-06-16, Breno Leitao <leitao@debian.org> wrote:
>> So this is not an issue since commit 7eab73b18630e ("netconsole: convert
>> to NBCON console infrastructure"). Because from here now on writes are
>> deferred to the nbcon thread. So this purely about -stable in this case.
>
> Does the nbcon thread handle defer even for consoles that support atomic
> operations?
The all "printk deferred" variants have zero effect on nbcon
drivers. The "printk deferred" variants exist purely as duct tape for
legacy console drivers.
If nbcon drivers provide a safe write_atomic(), they will _always_ write
synchronously when the CPU is in an emergency state. Otherwise nbcon
drivers _always_ defer to their dedicated console printing kthread and
there they use the write_thread() callback.
> netconsole is marked with CON_NBCON_ATOMIC_UNSAFE, which means it rarely
> performs inline/direct printk and instead pushes to the thread, which
> flushes in a safe context.
CON_NBCON_ATOMIC_UNSAFE means it _never_ performs inline/direct printk
console writing. That flags means that in panic, at the _very_ end, just
before going into an infinite nop loop, the CON_NBCON_ATOMIC_UNSAFE
consoles will be flushed directly from the panic context.
> For drivers that behave correctly, I'd like to be able to drop
> CON_NBCON_ATOMIC_UNSAFE, potentially setting it at runtime based on the
> underlying driver capabilities. If netconsole is backed by a well-behaving
> network driver, we could eventually remove the flag (!?)
>
> Would that approach cause any issues?
Removing the flag means the driver can safely write from _any_ context
(including scheduler and NMI), regardless what locks that context may be
holding.
Note that the nbcon framework allows console drivers to mark unsafe
regions in themselves, where atomic writing would not be possible. In
such scenarios, it defers to the dedicated printing kthread (except
during panic, where more agressive tactics are used).
John Ogness
^ permalink raw reply
* RE: [linux-next:master] [selftests] a3f88d89f6: kernel-selftests-bpf.net.test_bridge_neigh_suppress.sh.arping.fail
From: Danielle Ratson @ 2026-06-17 7:29 UTC (permalink / raw)
To: Oliver Sang
Cc: oe-lkp@lists.linux.dev, lkp@intel.com, Jakub Kicinski,
Nikolay Aleksandrov, netdev@vger.kernel.org
In-Reply-To: <ai/3+f7LJp6pyLJi@xsang-OptiPlex-9020>
Hi Oliver,
Thank you for confirming the arping version. ARPing 2.25 by Thomas Habets has incompatible semantics for several flags that the test relies on (-D, b, -U, -A).
So, the failures are a tool version issue rather than a kernel regression.
This is not limited to the new commit- looking at the 56 failures in the added log, the other arping-based test cases that existed before commit a3f88d89f698 are also failing, which confirms the root cause.
The same assumption (iputils arping) is made by other net selftests as well:
test_vxlan_nh.sh, forwarding/vxlan_asymmetric.sh, and arp_ndisc_untracked_subnets.sh all use iputils-specific flags.
There are two options to address this on your end:
1. Install iputils-arping and ensure it takes precedence over ARPing 2.25 in PATH. Running "arping -V" should then show "iputils".
2. If that is not feasible, I can send a fix that adds an iputils version check to test_bridge_neigh_suppress.sh, causing it to SKIP cleanly when iputils arping is not present:
if ! arping -V 2>&1 | grep -q "iputils"; then
echo "SKIP: Test requires iputils arping"
exit $ksft_skip
fi
This will result in a SKIP rather than a FAIL for your environment.
Thanks,
Danielle
> -----Original Message-----
> From: Oliver Sang <oliver.sang@intel.com>
> Sent: Monday, 15 June 2026 16:03
> To: Danielle Ratson <danieller@nvidia.com>
> Cc: oe-lkp@lists.linux.dev; lkp@intel.com; Jakub Kicinski <kuba@kernel.org>;
> Nikolay Aleksandrov <razor@blackwall.org>; netdev@vger.kernel.org;
> oliver.sang@intel.com
> Subject: Re: [linux-next:master] [selftests] a3f88d89f6: kernel-selftests-
> bpf.net.test_bridge_neigh_suppress.sh.arping.fail
>
> hi, Danielle,
>
> On Thu, Jun 11, 2026 at 11:44:39AM +0000, Danielle Ratson wrote:
> > Hi Oliver,
> >
> > Thank you for the report.
> >
> > The failures appear to be caused by an arping tool version mismatch.
> > The test was written assuming iputils arping semantics, but not all
> distributions ship that version. Different arping implementations have
> incompatible behavior for the flags used throughout
> test_bridge_neigh_suppress.sh.
> >
> > Looking at the added log, the 56 failures are not limited to the
> neigh_suppress_arp_probe section.
> > The other arping-based test cases in the file are also affected, which is
> consistent with a tool version issue rather than a kernel regression.
> >
> > To confirm the root cause on your end, please share the results for running
> the below:
> > $ arping -V
> > $ ./test_bridge_neigh_suppress.sh -t neigh_suppress_arp -v
>
> sorry for late.
>
> our tests run in a auto framework, I had to add some code to print above
> information, but so far, it just generates below output.
> before we try further, want to seek your advice if these information are
> enough?
>
> KERNEL SELFTESTS: linux_headers_dir is /usr/src/linux-headers-x86_64-rhel-
> 9.4-bpf-a3f88d89f698743a8cd91fb43f997e2d292a168d
> ### arping -V
> arping: option requires an argument -- 'V'
> ARPing 2.25, by Thomas Habets <thomas@habets.se>
> usage: arping [ -0aAbdDeFpPqrRuUvzZ ] [ -w <sec> ] [ -W <sec> ] [ -S <host/ip>
> ]
> [ -T <host/ip ] [ -s <MAC> ] [ -t <MAC> ] [ -c <count> ]
> [ -C <count> ] [ -i <interface> ] [ -m <type> ] [ -g <group> ]
> [ -V <vlan> ] [ -Q <priority> ] <host/ip/MAC | -B> For complete usage
> info, use --help or check the manpage.
> ### ./test_bridge_neigh_suppress.sh -t neigh_suppress_arp -v
> <-------- seems there is no output here
> Per-port ARP suppression - VLAN 10 <-------- seems already start the
> tests
> ----------------------------------
> COMMAND: tc -n sw1-U1mYwE qdisc replace dev vx0 clsact
>
>
> >
> > Thanks,
> > Danielle
> >
> > > -----Original Message-----
> > > From: kernel test robot <oliver.sang@intel.com>
> > > Sent: Thursday, 11 June 2026 10:23
> > > To: Danielle Ratson <danieller@nvidia.com>
> > > Cc: oe-lkp@lists.linux.dev; lkp@intel.com; Jakub Kicinski
> > > <kuba@kernel.org>; Nikolay Aleksandrov <razor@blackwall.org>;
> > > netdev@vger.kernel.org; oliver.sang@intel.com
> > > Subject: [linux-next:master] [selftests] a3f88d89f6:
> > > kernel-selftests- bpf.net.test_bridge_neigh_suppress.sh.arping.fail
> > >
> > >
> > > hi, Danielle Ratson,
> > >
> > > for new added tests, we still found some failures in our tests, not
> > > sure if any dependencies we missed? thanks
> > >
> > >
> > > Hello,
> > >
> > > kernel test robot noticed "kernel-selftests-
> > > bpf.net.test_bridge_neigh_suppress.sh.arping.fail" on:
> > >
> > > commit: a3f88d89f698743a8cd91fb43f997e2d292a168d ("selftests: net:
> > > Add tests for ARP probe and DAD NS handling")
> > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
> > > master
> > >
> > > in testcase: kernel-selftests-bpf
> > > version:
> > > with following parameters:
> > >
> > > group: net
> > >
> > >
> > > config: x86_64-rhel-9.4-bpf
> > > compiler: gcc-14
> > > test machine: 16 threads Intel(R) Core(TM) i7-13620H (Raptor Lake)
> > > with 32G memory
> > >
> > > (please refer to attached dmesg/kmsg for entire log/backtrace)
> > >
> > >
> > >
> > > If you fix the issue in a separate patch/commit (i.e. not just a new
> > > version of the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot <oliver.sang@intel.com>
> > > | Closes:
> > > | https://lore.kernel.org/oe-lkp/202606110955.8f29025d-lkp@intel.com
> > >
> > >
> > > # timeout set to 3600
> > > # selftests: net: test_bridge_neigh_suppress.sh #
> > >
> > > [...]
> > >
> > > #
> > > # Per-port ARP probe suppression
> > > # ------------------------------
> > > # TEST: ARP probe suppression [FAIL]
> > > # TEST: "neigh_suppress" is on [ OK ]
> > > # TEST: ARP probe suppression [FAIL]
> > > # TEST: FDB and neighbor entry installation [ OK ]
> > > # TEST: arping [FAIL]
> > > # TEST: ARP probe suppression [FAIL]
> > > # TEST: neighbor removal [ OK ]
> > > # TEST: ARP probe suppression [FAIL]
> > > # TEST: "neigh_suppress" is off [ OK ]
> > > # TEST: ARP probe suppression [FAIL]
> > > #
> > > # Per-port DAD NS suppression
> > > # ---------------------------
> > > # TEST: DAD NS suppression [ OK ]
> > > # TEST: "neigh_suppress" is on [ OK ]
> > > # TEST: DAD NS suppression [ OK ]
> > > # TEST: FDB and neighbor entry installation [ OK ]
> > > # TEST: DAD NS suppression [ OK ]
> > > # TEST: DAD NS proxy NA reply [ OK ]
> > > # TEST: neighbor removal [ OK ]
> > > # TEST: DAD NS suppression [ OK ]
> > > # TEST: "neigh_suppress" is off [ OK ]
> > > # TEST: DAD NS suppression [ OK ]
> > > #
> > > # Tests passed: 124
> > > # Tests failed: 56
> > > not ok 110 selftests: net: test_bridge_neigh_suppress.sh # exit=1
> > >
> > >
> > >
> > > The kernel config and materials to reproduce are available at:
> > > https://download.01.org/0day-
> > > ci/archive/20260611/202606110955.8f29025d-lkp@intel.com
> > >
> > >
> > >
> > > --
> > > 0-DAY CI Kernel Test Service
> > > https://github.com/intel/lkp-tests/wiki
> >
^ permalink raw reply
* Re: [TEST] vlan-bridge-binding-sh flaky
From: Ido Schimmel @ 2026-06-17 7:25 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, Petr Machata
In-Reply-To: <20260616092733.3a31be4d@kernel.org>
On Tue, Jun 16, 2026 at 09:27:33AM -0700, Jakub Kicinski wrote:
> Hi Ido!
>
> tools/testing/selftests/net/vlan_bridge_binding.sh got flaky recently.
>
> https://netdev.bots.linux.dev/contest.html?test=vlan-bridge-binding-sh
>
> Is it due to Eric's change or something else? Used to be pretty solid.
> First lake a week ago and 8 more since, before that for 3 weeks there
> were 0 flakes.
The failure reason is the same across all the test runs: Observing an UP
operational state instead of DOWN. I believe that's because link watch
can delay carrier loss events by up to 1 second and that's the timeout
the test is using.
I increased the timeout to 2 seconds and didn't observe a failure in
over 100 iterations. Previously it failed after 48 iterations.
I will send a patch.
^ permalink raw reply
* [PATCH net v2] ice: Fix use-after-scope in ice_sched_add_nodes_to_layer()
From: NeKon69 @ 2026-06-17 7:21 UTC (permalink / raw)
To: anthony.l.nguyen, przemyslaw.kitszel
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
piotr.kwapulinski, intel-wired-lan, netdev, linux-kernel, NeKon69
Commit 7fb09a737536 ("ice: Modify recursive way of adding nodes")
changed ice_sched_add_nodes_to_layer() from recursive control flow to an
iterative loop.
Inside the loop, first_teid_ptr may be set to the address of a
block-local variable:
u32 temp;
...
if (num_added)
first_teid_ptr = &temp;
On the next loop iteration, first_teid_ptr may be passed to
ice_sched_add_nodes_to_hw_layer(), after temp from the previous
iteration has gone out of scope.
Instead of keeping temporary storage for later calls, allow
first_node_teid to be NULL when the caller does not need the TEID.
This was found by Clang with LifetimeSafety enabled while testing C
language support on a Linux allmodconfig build.
Fixes: 7fb09a737536 ("ice: Modify recursive way of adding nodes")
Link: https://github.com/llvm/llvm-project/pull/203270
Signed-off-by: NeKon69 <nobodqwe@gmail.com>
---
v2:
- Allow first_node_teid to be NULL when callers do not need the TEID.
- Pass NULL after the first TEID has already been returned instead of using
temporary stack storage.
- Update kernel-doc for helpers accepting NULL.
- Link to v1: https://lore.kernel.org/netdev/20260613101440.80190-1-nobodqwe@gmail.com/
- Compile-tested with:
make drivers/net/ethernet/intel/ice/ice_sched.o
drivers/net/ethernet/intel/ice/ice_sched.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_sched.c b/drivers/net/ethernet/intel/ice/ice_sched.c
index fff0c1afdb41..89e191c839b1 100644
--- a/drivers/net/ethernet/intel/ice/ice_sched.c
+++ b/drivers/net/ethernet/intel/ice/ice_sched.c
@@ -895,7 +895,8 @@ void ice_sched_cleanup_all(struct ice_hw *hw)
* @layer: layer number to add nodes
* @num_nodes: number of nodes
* @num_nodes_added: pointer to num nodes added
- * @first_node_teid: if new nodes are added then return the TEID of first node
+ * @first_node_teid: if new nodes are added then return the TEID of first node,
+ * may be NULL
* @prealloc_nodes: preallocated nodes struct for software DB
*
* This function add nodes to HW as well as to SW DB for a given layer
@@ -1000,7 +1001,7 @@ ice_sched_add_elems(struct ice_port_info *pi, struct ice_sched_node *tc_node,
if (!pi->sib_head[tc_node->tc_num][layer])
pi->sib_head[tc_node->tc_num][layer] = new_node;
- if (i == 0)
+ if (first_node_teid && i == 0)
*first_node_teid = teid;
}
@@ -1015,7 +1016,7 @@ ice_sched_add_elems(struct ice_port_info *pi, struct ice_sched_node *tc_node,
* @parent: pointer to parent node
* @layer: layer number to add nodes
* @num_nodes: number of nodes to be added
- * @first_node_teid: pointer to the first node TEID
+ * @first_node_teid: pointer to the first node TEID, may be NULL
* @num_nodes_added: pointer to number of nodes added
*
* Add nodes into specific HW layer.
@@ -1078,7 +1079,6 @@ ice_sched_add_nodes_to_layer(struct ice_port_info *pi,
*num_nodes_added = 0;
while (*num_nodes_added < num_nodes) {
u16 max_child_nodes, num_added = 0;
- u32 temp;
status = ice_sched_add_nodes_to_hw_layer(pi, tc_node, parent,
layer, new_num_nodes,
@@ -1109,13 +1109,11 @@ ice_sched_add_nodes_to_layer(struct ice_port_info *pi,
* try the next available sibling.
*/
parent = ice_sched_find_next_vsi_node(parent);
- /* Don't modify the first node TEID memory if the
- * first node was added already in the above call.
- * Instead send some temp memory for all other
- * recursive calls.
+ /* Don't modify the first node TEID memory if the first node
+ * was added already in the above call.
*/
if (num_added)
- first_teid_ptr = &temp;
+ first_teid_ptr = NULL;
new_num_nodes = num_nodes - *num_nodes_added;
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] net: airoha: Fix off-by-one error in HTB rate-limit channel removal
From: Lorenzo Bianconi @ 2026-06-17 7:13 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178166483303.2209640.10761097847073356089@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]
> In airoha_tc_remove_htb_queue(), the rate-limit was being cleared
> using (queue + 1) instead of queue, causing:
> - The original channel rate-limit configuration to remain active
> - The next channel to be incorrectly disabled
> - Potential out-of-bounds access when queue == 3 (channel 4)
>
> The alloc path (airoha_tc_htb_alloc_leaf_queue) correctly uses
> channel (0..3), but the remove path incorrectly added 1.
>
> Fix by using queue directly to match the alloc and rollback paths.
>
> Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Wayen Yan <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11cd7..02807b3967 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2805,7 +2805,7 @@ static void airoha_tc_remove_htb_queue(struct net_device *dev, int queue)
> struct airoha_gdm_port *port = netdev_priv(dev);
>
> netif_set_real_num_tx_queues(dev, dev->real_num_tx_queues - 1);
> - airoha_qdma_set_tx_rate_limit(dev, queue + 1, 0, 0);
> + airoha_qdma_set_tx_rate_limit(dev, queue, 0, 0);
> clear_bit(queue, port->qos_sq_bmap);
> }
Please hold on with this patch, I am aware of the bug and the fix is already in
my queue [0]. I am just waiting the net-next to be merged into net in order to
avoid merge conflicts.
Regards,
Lorenzo
[0] https://github.com/LorenzoBianconi/net-next/commits/airoha-qos-fixes-for-net/
>
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix TX scheduler queue mask loop upper bound
From: Lorenzo Bianconi @ 2026-06-17 7:10 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178166704952.2212140.11002626760717132754@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]
> In airoha_qdma_set_chan_tx_sched(), the loop clearing queue mask was
> using AIROHA_NUM_TX_RING (32) instead of AIROHA_NUM_QOS_QUEUES (8).
>
> Each channel has 8 queues, and TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i)
> computes BIT(i + (channel * 8)). With i ranging 0..31, this causes:
> - channel 0: clears bit 0..31 (all 4 channels) instead of 0..7
> - channel 1: clears bit 8..31 (channels 1-3) instead of 8..15
> - channel 2: clears bit 16..31 (channels 2-3) instead of 16..23
> - channel 3: clears bit 24..31 (channel 3 only) - correct by accident
>
> While BIT(32+) on arm64 produces 64-bit values truncated to 0 in u32
> mask parameter, the loop still incorrectly clears queues within the
> same channel beyond queue 7.
>
> Fix by using AIROHA_NUM_QOS_QUEUES (8) as the loop upper bound.
>
> Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Wayen Yan <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11cd7..a1eda13400 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2217,7 +2217,7 @@ static int airoha_qdma_set_chan_tx_sched(struct net_device *dev,
> struct airoha_gdm_port *port = netdev_priv(dev);
> int i;
>
> - for (i = 0; i < AIROHA_NUM_TX_RING; i++)
> + for (i = 0; i < AIROHA_NUM_QOS_QUEUES; i++)
> airoha_qdma_clear(port->qdma, REG_QUEUE_CLOSE_CFG(channel),
> TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i));
Even if the current codebase supports just AIROHA_NUM_QOS_CHANNEL (4), the hw
exposes 32 hw QoS channels (AIROHA_NUM_TX_RING). Here we are just clearing the
configuration, so I guess the current implementation is correct.
Regards,
Lorenzo
>
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths
From: Lorenzo Bianconi @ 2026-06-17 6:58 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178167550101.2217645.14579307712717502425@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]
> In mtk_ppe_init(), when accounting is enabled, the error paths for
> dmam_alloc_coherent(mib) and devm_kzalloc(acct) failures return NULL
> directly, bypassing the err_free_l2_flows label that destroys the
> rhashtable initialized earlier.
>
> While this leak only occurs during probe (not runtime) and the leaked
> memory is minimal (an empty rhash table), fixing it ensures proper
> error path cleanup consistency.
>
> Fix by changing the two return NULL statements to goto err_free_l2_flows.
>
> Fixes: 603ea5e7ffa7 ("net: ethernet: mtk_eth_soc: fix memory leak in error path")
> Signed-off-by: Wayen Yan <win847@gmail.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/mediatek/mtk_ppe.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.c b/drivers/net/ethernet/mediatek/mtk_ppe.c
> index 18279e2a70..8451dc3fd0 100644
> --- a/drivers/net/ethernet/mediatek/mtk_ppe.c
> +++ b/drivers/net/ethernet/mediatek/mtk_ppe.c
> @@ -918,7 +918,7 @@ struct mtk_ppe *mtk_ppe_init(struct mtk_eth *eth, void __iomem *base, int index)
> mib = dmam_alloc_coherent(ppe->dev, MTK_PPE_ENTRIES * sizeof(*mib),
> &ppe->mib_phys, GFP_KERNEL);
> if (!mib)
> - return NULL;
> + goto err_free_l2_flows;
>
> ppe->mib_table = mib;
>
> @@ -926,7 +926,7 @@ struct mtk_ppe *mtk_ppe_init(struct mtk_eth *eth, void __iomem *base, int index)
> GFP_KERNEL);
>
> if (!acct)
> - return NULL;
> + goto err_free_l2_flows;
>
> ppe->acct_table = acct;
> }
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH net] ipv6: ndisc: fix NULL deref in accept_untracked_na()
From: Weiming Shi @ 2026-06-17 6:55 UTC (permalink / raw)
To: David S . Miller, David Ahern, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Simon Horman, netdev, linux-kernel, Xiang Mei, Weiming Shi
accept_untracked_na() re-fetches the inet6_dev with __in6_dev_get(dev)
and dereferences idev->cnf.accept_untracked_na without a NULL check,
even though its only caller ndisc_recv_na() already fetched and
NULL-checked idev for the same device.
Both reads of dev->ip6_ptr run in the same RCU read-side critical
section, but a concurrent addrconf_ifdown() can clear dev->ip6_ptr
between them: lowering the MTU below IPV6_MIN_MTU calls addrconf_ifdown()
without the synchronize_net() that orders the unregister path, so the
re-fetch returns NULL and oopses:
BUG: KASAN: null-ptr-deref in ndisc_recv_na (net/ipv6/ndisc.c:974)
Read of size 4 at addr 0000000000000364
Call Trace:
<IRQ>
ndisc_recv_na (net/ipv6/ndisc.c:974)
icmpv6_rcv (net/ipv6/icmp.c:1193)
ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479)
ip6_input_finish (net/ipv6/ip6_input.c:534)
ip6_input (net/ipv6/ip6_input.c:545)
ip6_mc_input (net/ipv6/ip6_input.c:635)
ipv6_rcv (net/ipv6/ip6_input.c:351)
</IRQ>
It is reachable by an unprivileged user via a network namespace.
Pass the caller's already validated idev instead of re-fetching it; the
idev stays alive for the whole RCU critical section, so it is safe even
after dev->ip6_ptr has been cleared.
Fixes: aaa5f515b16b ("net: ipv6: new accept_untracked_na option to accept na only if in-network")
Assisted-by: Claude:claude-opus-4-8
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
net/ipv6/ndisc.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index e7ad13c5bd267..f867ec8d3d905 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -967,10 +967,8 @@ static enum skb_drop_reason ndisc_recv_ns(struct sk_buff *skb)
return reason;
}
-static int accept_untracked_na(struct net_device *dev, struct in6_addr *saddr)
+static int accept_untracked_na(struct inet6_dev *idev, struct in6_addr *saddr)
{
- struct inet6_dev *idev = __in6_dev_get(dev);
-
switch (READ_ONCE(idev->cnf.accept_untracked_na)) {
case 0: /* Don't accept untracked na (absent in neighbor cache) */
return 0;
@@ -980,7 +978,7 @@ static int accept_untracked_na(struct net_device *dev, struct in6_addr *saddr)
* same subnet as an address configured on the interface that
* received the na
*/
- return !!ipv6_chk_prefix(saddr, dev);
+ return !!ipv6_chk_prefix(saddr, idev->dev);
default:
return 0;
}
@@ -1078,7 +1076,7 @@ static enum skb_drop_reason ndisc_recv_na(struct sk_buff *skb)
*/
new_state = msg->icmph.icmp6_solicited ? NUD_REACHABLE : NUD_STALE;
if (!neigh && lladdr && idev && READ_ONCE(idev->cnf.forwarding)) {
- if (accept_untracked_na(dev, saddr)) {
+ if (accept_untracked_na(idev, saddr)) {
neigh = neigh_create(&nd_tbl, &msg->target, dev);
new_state = NUD_STALE;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next v2 1/2] dt-bindings: net: pse-pd: add bindings for Realtek/Broadcom PSE MCU
From: Jonas Jelonek @ 2026-06-17 6:50 UTC (permalink / raw)
To: Rob Herring
Cc: Oleksij Rempel, Kory Maincent, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Krzysztof Kozlowski,
Conor Dooley, netdev, devicetree, linux-kernel, Daniel Golle,
Bjørn Mork
In-Reply-To: <20260615212959.GA1679454-robh@kernel.org>
Hi Rob,
On 15.06.26 23:29, Rob Herring wrote:
> On Fri, Jun 12, 2026 at 01:29:41PM +0000, Jonas Jelonek wrote:
>> [...]
>>
>> +properties:
>> + compatible:
>> + enum:
>> + - realtek,pse-mcu-rtk
> The "rtk" feels redundant.
In the full Realtek case yes. Do you have a suggestion to improve
that?
>> + - realtek,pse-mcu-bcm
> "brcm" is the standard vendor prefix, so use that instead of "bcm".
> Though who defined the protocol in this case? Realtek or Broadcom? In
> the latter case, I'd argue that "brcm" should be the vendor prefix.
I'll switch to brcm.
As Daniel already mentioned, Realtek defines the firmware and thus
the protocol, in both cases.
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + power-supply:
>> + description: Regulator supplying the PoE power rail.
>> +
>> + enable-gpios:
>> + maxItems: 1
>> +
>> + realtek,i2c-protocol:
>> + $ref: /schemas/types.yaml#/definitions/string
>> + enum: [ i2c, smbus ]
>> + description: |
>> + Wire framing the MCU firmware expects on the I2C bus. "smbus" means
>> + reads carry a leading command byte (0x00) and a repeated start; "i2c"
>> + means bare 12-byte writes and reads with no command prefix. Only
>> + applies to the Realtek I2C attachment.
> I tend to think this should be distinguished by the compatible string.
> That would simplify the schema given it only applies to one of the
> compatible strings.
In theory this could also apply to the Broadcom dialect, however I didn't
have a device with that variant on my desk.
If you would go with separate compatibles, do you thought about
something like "realtek,pse-mcu-rtk-i2c" and
"realtek,pse-mcu-rtk-smbus" (given we stick with rtk) ?
> Rob
Best regards,
Jonas
^ permalink raw reply
* Re: [PATCH net] nfc: pn533: prevent division by zero in the listen mode timer
From: Yinhao Hu @ 2026-06-17 6:48 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, David Heidelberg, Krzysztof Kozlowski, Jakub Kicinski,
Dan Carpenter, dzm91, hust-os-kernel-patches
In-Reply-To: <20260616140209.GU712698@horms.kernel.org>
On 6/16/26 10:02 PM, Simon Horman wrote:
> On Mon, Jun 15, 2026 at 03:35:47AM -0700, Yinhao Hu wrote:
>> The listen-mode timer handler advances the polling state machine through
>> pn533_poll_next_mod(), which computes:
>>
>> dev->poll_mod_curr = (dev->poll_mod_curr + 1) % dev->poll_mod_count;
>>
>> pn533_poll_reset_mod_list() clears dev->poll_mod_count without first
>> stopping that timer: pn533_dep_link_down() deletes no timer at all, and
>> pn533_stop_poll() uses timer_delete(), which does not wait for a handler
>> already running on another CPU. When the handler runs after the count
>> has been zeroed, it divides by zero:
>>
>> Oops: divide error: 0000 [#1] SMP
>> RIP: 0010:pn533_listen_mode_timer+0x9b/0x110
>>
>> Delete the timer synchronously in pn533_poll_reset_mod_list(), the single
>> place that clears the list, so the handler can no longer run past a reset.
>> Also return early when poll_mod_count is already zero, covering the window
>> where pn533_wq_poll() re-arms the timer just before a reset.
>>
>> Fixes: 6fbbdc16be38 ("NFC: Implement pn533 polling loop")
>> Signed-off-by: Yinhao Hu <dddddd@hust.edu.cn>
>> ---
>> drivers/nfc/pn533/pn533.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
>> index d7bdbc82e2ba..88df99001b4a 100644
>> --- a/drivers/nfc/pn533/pn533.c
>> +++ b/drivers/nfc/pn533/pn533.c
>> @@ -951,6 +951,7 @@ static inline void pn533_poll_next_mod(struct pn533 *dev)
>>
>> static void pn533_poll_reset_mod_list(struct pn533 *dev)
>> {
>> + timer_delete_sync(&dev->listen_timer);
>> dev->poll_mod_count = 0;
>> }
>>
>> @@ -1235,6 +1236,10 @@ static void pn533_listen_mode_timer(struct timer_list *t)
>> {
>> struct pn533 *dev = timer_container_of(dev, t, listen_timer);
>>
>> + /* Polling may have been stopped while the timer was pending. */
>> + if (!dev->poll_mod_count)
>> + return;
>> +
>
> I am concerned that access to poll_mod_count is not synchronised and thus
> this may not work as intended.
>
Thanks for the review.
The guard's read is lockless, but it isn't what makes the fix safe;
timer_delete_sync() is. pn533_poll_reset_mod_list() is the only place
that clears the count, and it now syncs the timer before the store, so
the handler can't be mid-pn533_poll_next_mod() when the count is zeroed.
The early return is just a backstop for a timer re-armed after that
reset, and it mirrors the existing lockless guard in
pn533_poll_complete() ahead of the other pn533_poll_next_mod() call, the
same pattern already in-tree.
If you'd still prefer the lockless accesses marked explicitly, I can add
READ_ONCE()/WRITE_ONCE() in v2.
>> dev->cancel_listen = 1;
>>
>> pn533_poll_next_mod(dev);
>> --
>> 2.43.0
>>
^ permalink raw reply
* Re: [PATCH net-next] gre: fix ERSPAN o_flags race/corruption in xmit and fill_info
From: Ido Schimmel @ 2026-06-17 6:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
David Ahern, netdev, eric.dumazet
In-Reply-To: <20260615140333.3161072-1-edumazet@google.com>
On Mon, Jun 15, 2026 at 02:03:33PM +0000, Eric Dumazet wrote:
> @@ -692,7 +689,7 @@ static netdev_tx_t ipgre_xmit(struct sk_buff *skb,
> tunnel->parms.o_flags)))
> goto free_skb;
>
> - __gre_xmit(skb, dev, tnl_params, skb->protocol);
> + __gre_xmit(skb, dev, tnl_params, skb->protocol, tunnel->parms.o_flags);
> return NETDEV_TX_OK;
>
> free_skb:
> @@ -705,6 +702,7 @@ static netdev_tx_t erspan_xmit(struct sk_buff *skb,
> struct net_device *dev)
> {
> struct ip_tunnel *tunnel = netdev_priv(dev);
> + IP_TUNNEL_DECLARE_FLAGS(flags);
> bool truncate = false;
> __be16 proto;
>
> @@ -728,10 +726,12 @@ static netdev_tx_t erspan_xmit(struct sk_buff *skb,
> truncate = true;
> }
>
> + ip_tunnel_flags_copy(flags, tunnel->parms.o_flags);
> +
> /* Push ERSPAN header */
> if (tunnel->erspan_ver == 0) {
> proto = htons(ETH_P_ERSPAN);
> - __clear_bit(IP_TUNNEL_SEQ_BIT, tunnel->parms.o_flags);
> + __clear_bit(IP_TUNNEL_SEQ_BIT, flags);
> } else if (tunnel->erspan_ver == 1) {
> erspan_build_header(skb, ntohl(tunnel->parms.o_key),
> tunnel->index,
> @@ -746,8 +746,8 @@ static netdev_tx_t erspan_xmit(struct sk_buff *skb,
> goto free_skb;
> }
>
> - __clear_bit(IP_TUNNEL_KEY_BIT, tunnel->parms.o_flags);
> - __gre_xmit(skb, dev, &tunnel->parms.iph, proto);
> + __clear_bit(IP_TUNNEL_KEY_BIT, flags);
> + __gre_xmit(skb, dev, &tunnel->parms.iph, proto, flags);
> return NETDEV_TX_OK;
>
> free_skb:
> @@ -776,7 +776,7 @@ static netdev_tx_t gre_tap_xmit(struct sk_buff *skb,
> if (skb_cow_head(skb, dev->needed_headroom))
> goto free_skb;
>
> - __gre_xmit(skb, dev, &tunnel->parms.iph, htons(ETH_P_TEB));
> + __gre_xmit(skb, dev, &tunnel->parms.iph, htons(ETH_P_TEB), tunnel->parms.o_flags);
Eric, did you see the feedback from Sashiko [1]?
WDYT about aligning ipgre and gretap with erspan and passing a copy of
the output flags to __gre_xmit() instead of passing
'tunnel->parms.o_flags' directly?
The mismatch between the output flags and the tunnel header length is a
different issue (pre-existing).
[1] https://sashiko.dev/#/patchset/20260615140333.3161072-1-edumazet%40google.com
> return NETDEV_TX_OK;
>
> free_skb:
^ 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