* [PATCH] dpaa2-switch: put MAC endpoint device on disconnect
From: Guangshuo Li @ 2026-07-08 11:10 UTC (permalink / raw)
To: Ioana Ciornei, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
Cc: Guangshuo Li
fsl_mc_get_endpoint() returns the MAC endpoint device with a reference
taken through device_find_child(). The switch port connect path stores
that device in mac->mc_dev and keeps it for the lifetime of the connected
MAC object.
However, the disconnect path only closes the MAC and frees the dpaa2_mac
object. It does not drop the endpoint device reference stored in
mac->mc_dev, so every successful connect leaks that device reference when
the MAC is later disconnected.
Drop the endpoint device reference before freeing the dpaa2_mac object.
Fixes: 84cba72956fd ("dpaa2-switch: integrate the MAC endpoint support")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c
index 858ba844ac51..dd4f60031d0c 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c
@@ -1560,6 +1560,7 @@ static void dpaa2_switch_port_disconnect_mac(struct ethsw_port_priv *port_priv)
dpaa2_mac_disconnect(mac);
dpaa2_mac_close(mac);
+ put_device(&mac->mc_dev->dev);
kfree(mac);
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next v4] selftests/net/openvswitch: add ICMPv6 echo type match test
From: Paolo Abeni @ 2026-07-08 11:15 UTC (permalink / raw)
To: Minxi Hou, netdev
Cc: aconole, echaudro, i.maximets, davem, edumazet, kuba, horms,
shuah, dev, linux-kselftest
In-Reply-To: <20260702075044.1176798-1-houminxi@gmail.com>
On 7/2/26 9:50 AM, Minxi Hou wrote:
> Register OVS_KEY_ATTR_ICMPV6 in the flow key parser so that
> icmpv6(type=...) can be used in flow specifications. Without this
> registration the parser silently drops the token and the kernel
> rejects the flow with EINVAL because the expected ICMPv6 key
> attribute is missing.
>
> While here, add convert_int() to the ovs_key_ipv6 and ovs_key_icmp
> fields_map entries so that specifying a field value produces the
> correct wildcard mask. The IPv6 flow label uses convert_int(20) to
> produce a 20-bit mask (0x000FFFFF), matching the kernel constraint in
> flow_netlink.c that rejects masks with bits 20-31 set; byte-wide
> fields use convert_int(8). The ipv4 counterpart already does this via
> convert_int(); the ipv6 and icmp classes were simply missing the fifth
> tuple element. Existing callers that pass empty parentheses are
> unaffected because convert_int("") returns (0, 0).
>
> Add test_icmpv6 exercising the ICMPv6 echo flow key. The test uses
> static neighbour entries with nud permanent to prevent racy NDP, then
> verifies in three steps: install icmpv6(type=128) and
> icmpv6(type=129) flows and confirm ping works, remove the flows and
> confirm ping fails, reinstall and confirm recovery.
>
> Signed-off-by: Minxi Hou <houminxi@gmail.com>
Does not apply cleanly anymore. Please rebase and resend. Note that you
can retain Aaron's ack.
/P
^ permalink raw reply
* Re: [PATCH net-next v3] net: skb: isolate skb data area allocations into a separate bucket
From: Pedro Falcato @ 2026-07-08 11:16 UTC (permalink / raw)
To: Paolo Abeni
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Simon Horman,
Jason Xing, Kuniyuki Iwashima, netdev, linux-kernel,
linux-hardening, Kees Cook, linux-mm, Vlastimil Babka, Harry Yoo
In-Reply-To: <04debe19-bbe8-4b5f-9668-753d1f97832d@redhat.com>
On Wed, Jul 08, 2026 at 10:30:50AM +0200, Paolo Abeni wrote:
> On 7/2/26 7:07 PM, Pedro Falcato wrote:> @@ -586,6 +586,8 @@ struct
> sk_buff *napi_build_skb(void *data, unsigned int frag_size)
> > }
> > EXPORT_SYMBOL(napi_build_skb);
> >
> > +static kmem_buckets *skb_data_buckets __ro_after_init;
> > +
> > static void *kmalloc_pfmemalloc(size_t obj_size, gfp_t flags, int node)
> > {
> > if (!gfp_pfmemalloc_allowed(flags))
> > @@ -593,7 +595,8 @@ static void *kmalloc_pfmemalloc(size_t obj_size, gfp_t flags, int node)
> > if (!obj_size)
> > return kmem_cache_alloc_node(net_hotdata.skb_small_head_cache,
> > flags, node);
> > - return kmalloc_node_track_caller(obj_size, flags, node);
> > + return kmem_buckets_alloc_node_track_caller(skb_data_buckets, obj_size,
> > + flags, node);
>
> Sashiko noted that some drivers may require GFP_DMA buckets, and the
> above may break them:
>
> https://sashiko.dev/#/patchset/20260702170728.168755-1-pfalcato%40suse.de
Oh, this is really awkward. Adding linux-mm and slab maintainers for input here.
Considering the current slab bucketing does not seem to duplicate DMA or
CGROUP caches, could it make sense to duplicate those as well? Otherwise we
could add a branch like:
if (gfp_flags & __GFP_DMA)
/* use the global dma kmalloc caches */
>
> > }
> >
> > /*
> > @@ -634,7 +637,7 @@ static void *kmalloc_reserve(unsigned int *size, gfp_t flags, int node,
> > * Try a regular allocation, when that fails and we're not entitled
> > * to the reserves, fail.
> > */
> > - obj = kmalloc_node_track_caller(obj_size,
> > + obj = kmem_buckets_alloc_node_track_caller(skb_data_buckets, obj_size,
> > flags | __GFP_NOMEMALLOC | __GFP_NOWARN,
> > node);
>
> Minor nit: checkpatch laments WRT brackets alignment.
Will fix, thanks.
--
Pedro
^ permalink raw reply
* [PATCH] dpaa2-eth: put MAC endpoint device on disconnect
From: Guangshuo Li @ 2026-07-08 11:17 UTC (permalink / raw)
To: Ioana Ciornei, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
Cc: Guangshuo Li
fsl_mc_get_endpoint() returns the MAC endpoint device with a reference
taken through device_find_child(). The Ethernet connect path stores that
device in mac->mc_dev and keeps it for the lifetime of the connected MAC
object.
However, the disconnect path only disconnects and closes the MAC before
freeing the dpaa2_mac object. It does not drop the endpoint device
reference stored in mac->mc_dev, so every successful connect leaks that
device reference when the MAC is later disconnected.
Drop the endpoint device reference after closing the MAC and before
freeing the dpaa2_mac object.
Fixes: 719479230893 ("dpaa2-eth: add MAC/PHY support through phylink")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
index 9335703768a9..764d2a09668f 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
@@ -4732,6 +4732,7 @@ static void dpaa2_eth_disconnect_mac(struct dpaa2_eth_priv *priv)
dpaa2_mac_disconnect(mac);
dpaa2_mac_close(mac);
+ put_device(&mac->mc_dev->dev);
kfree(mac);
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] ppp/ppp_{async,synctty}: drop unused {a,}syncppp::bytes_{sent,rcvd}
From: patchwork-bot+netdevbpf @ 2026-07-08 11:20 UTC (permalink / raw)
To: Jiri Slaby
Cc: kuba, linux-kernel, andrew+netdev, davem, edumazet, pabeni,
linux-ppp, netdev
In-Reply-To: <20260702060420.95023-1-jirislaby@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Thu, 2 Jul 2026 08:04:20 +0200 you wrote:
> The bytes_sent and bytes_rcvd members of structs asyncppp and syncppp
> are not used. Drop them.
>
> Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
> Cc: Andrew Lunn <andrew+netdev@lunn.ch>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
>
> [...]
Here is the summary with links:
- ppp/ppp_{async,synctty}: drop unused {a,}syncppp::bytes_{sent,rcvd}
https://git.kernel.org/netdev/net-next/c/155c68aef239
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH net-next] net: ipip: use tunnel parameters for fill_forward_path route lookup
From: Lorenzo Bianconi @ 2026-07-08 11:25 UTC (permalink / raw)
To: David Ahern, Ido Schimmel, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Pablo Neira Ayuso,
Florian Westphal
Cc: netdev, netfilter-devel, Lorenzo Bianconi
Pass source address, DSCP and output interface from the tunnel
configuration to ip_route_output() in ipip_fill_forward_path(), aligning
the route lookup with the slow path in ipip_tunnel_xmit().
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
net/ipv4/ipip.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index b643194f57d2..d1aa048a6099 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -360,8 +360,9 @@ static int ipip_fill_forward_path(struct net_device_path_ctx *ctx,
const struct iphdr *tiph = &tunnel->parms.iph;
struct rtable *rt;
- rt = ip_route_output(dev_net(ctx->dev), tiph->daddr, 0, 0, 0,
- RT_SCOPE_UNIVERSE);
+ rt = ip_route_output(dev_net(ctx->dev), tiph->daddr, tiph->saddr,
+ inet_dsfield_to_dscp(tiph->tos),
+ tunnel->parms.link, RT_SCOPE_UNIVERSE);
if (IS_ERR(rt))
return PTR_ERR(rt);
---
base-commit: 155c68aef2397f8c5d72ef10acf48ae159bf1869
change-id: 20260708-ipip-route-lookup-fill_forward_path-6a8a1f45084c
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* [PATCH net] net: airoha: Fix potential use-after-free in airoha_ppe_deinit()
From: Wayen Yan @ 2026-07-08 11:16 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
airoha_ppe_deinit() replaces the NPU pointer with NULL via
rcu_replace_pointer() but does not wait for existing RCU readers
to exit before calling ppe_deinit() and airoha_npu_put(). This can
cause a use-after-free if a reader in an RCU read-side critical
section still holds a reference to the NPU when it is freed.
The init path (airoha_ppe_init) already calls synchronize_rcu()
after rcu_assign_pointer(), but the deinit path introduced in
commit 6abcf751bc08 ("net: airoha: Fix schedule while atomic in
airoha_ppe_deinit()") omitted the matching barrier when switching
from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer().
Add synchronize_rcu() before ppe_deinit() to ensure all existing
RCU readers have completed before the NPU resources are released.
Fixes: 6abcf751bc084804a9e5b3051442e8a2ce67f48a ("net: airoha: Fix schedule while atomic in airoha_ppe_deinit()")
Signed-off-by: Wayen Yan <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_ppe.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
index e7c78293002a..f6396925722d 100644
--- a/drivers/net/ethernet/airoha/airoha_ppe.c
+++ b/drivers/net/ethernet/airoha/airoha_ppe.c
@@ -1659,6 +1659,7 @@ void airoha_ppe_deinit(struct airoha_eth *eth)
npu = rcu_replace_pointer(eth->npu, NULL,
lockdep_is_held(&flow_offload_mutex));
if (npu) {
+ synchronize_rcu();
npu->ops.ppe_deinit(npu);
airoha_npu_put(npu);
}
--
2.51.0
^ permalink raw reply related
* [PATCH net] net: airoha: Fix DMA direction for NPU mailbox buffer
From: Wayen Yan @ 2026-07-08 11:35 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE,
but some callers expect the NPU to write response data back into the
same buffer:
- airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into
the buffer, then the caller reads it via memcpy()
- airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back
npu_stats_addr field in the response
On non-cache-coherent architectures like EN7581 (Cortex-A53 without
hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op
— it does not invalidate the CPU cache. If the NPU-written cache line
is still present in the CPU cache when the caller reads the buffer,
the CPU observes stale data instead of the NPU response.
This is a timing-sensitive bug: small mailbox buffers (~24 bytes)
typically fit in a single cache line and may survive in the cache
until the caller reads them, producing silent data corruption rather
than a crash. The bug is more likely to trigger when the caller reads
the response immediately after dma_unmap_single() without intervening
cache-evicting operations.
Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures
dma_unmap_single() invalidates the CPU cache on non-coherent systems.
The mailbox buffers are small so there is no performance concern.
Fixes: c52918744ee1e49cea86622a2633b9782446428f ("net: airoha: npu: Move memory allocation in airoha_npu_send_msg() caller")
Signed-off-by: Wayen Yan <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_npu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_npu.c b/drivers/net/ethernet/airoha/airoha_npu.c
index 870d61fdd9c6..b679bed952de 100644
--- a/drivers/net/ethernet/airoha/airoha_npu.c
+++ b/drivers/net/ethernet/airoha/airoha_npu.c
@@ -168,7 +168,7 @@ static int airoha_npu_send_msg(struct airoha_npu *npu, int func_id,
dma_addr_t dma_addr;
int ret;
- dma_addr = dma_map_single(npu->dev, p, size, DMA_TO_DEVICE);
+ dma_addr = dma_map_single(npu->dev, p, size, DMA_BIDIRECTIONAL);
ret = dma_mapping_error(npu->dev, dma_addr);
if (ret)
return ret;
@@ -191,7 +191,7 @@ static int airoha_npu_send_msg(struct airoha_npu *npu, int func_id,
spin_unlock_bh(&npu->cores[core].lock);
- dma_unmap_single(npu->dev, dma_addr, size, DMA_TO_DEVICE);
+ dma_unmap_single(npu->dev, dma_addr, size, DMA_BIDIRECTIONAL);
return ret;
}
--
2.51.0
^ permalink raw reply related
* Re: [PATCH net-next 1/6] dt-bindings: net: mediatek-dwmac: add support for MT8189 SoC
From: Louis-Alexis Eyraud @ 2026-07-08 11:36 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Matthias Brugger, AngeloGioacchino Del Regno,
Biao Huang, Maxime Coquelin, Alexandre Torgue, maxime.chevallier,
rmk+kernel, kernel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-stm32
In-Reply-To: <b810b9cd-8f5e-4c9d-8496-908aae55dac1@lunn.ch>
Hi Andrew,
On Tue, 2026-07-07 at 14:42 +0200, Andrew Lunn wrote:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - mediatek,mt8189-gmac
> > + then:
> > + properties:
> > + clocks:
> > + items:
> > + - description: MAC Main clock
> > + - description: PTP clock
> > + - description: RMII reference clock provided by MAC
>
> Since this is a MAC, it sounds like it is consuming its own clock?
In the driver ([1]), this clock is described as being only used and
needed in RMII when MAC provides the reference clock, and useless
otherwise (RGMII/MII or RMII when PHY provides the reference clock).
Its use and configuration also depends on the "mediatek,rmii-clk-from-
mac" vendor property ([2]) presence in devicetree.
Do you wish this clock description be reworded in the dt-bindings for
both occurrences?
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c#n480
[2]:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml#n108
Regards,
Louis-Alexis
>
> Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/6] net: stmmac: mediatek: add PERI_ETH_CTRLx register offset in platform data
From: Louis-Alexis Eyraud @ 2026-07-08 11:44 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Matthias Brugger, AngeloGioacchino Del Regno,
Biao Huang, Maxime Coquelin, Alexandre Torgue, maxime.chevallier,
rmk+kernel, kernel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-stm32
In-Reply-To: <3e135fe0-4ef9-45be-a962-d131c8a2e9e0@lunn.ch>
Hi Andrew
On Tue, 2026-07-07 at 14:45 +0200, Andrew Lunn wrote:
> > + .peri_eth_ctrl_offset = MT8195_PERI_ETH_CTRL_BASE,
>
> nitpick:
>
> Could the naming be more consistent? offset vs base?
>
> Andrew
Ack.
The commit description and subject also use offset terminology and not
base so better keep the consistency.
I'll rename this define to MT8195_PERI_ETH_CTRL_OFFSET in the v2
version and do the same for the MT8189 one in patch 6.
Regards,
Louis-Alexis
^ permalink raw reply
* Re: [PATCH net] netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()
From: Florian Westphal @ 2026-07-08 11:45 UTC (permalink / raw)
To: Xiang Mei (Microsoft)
Cc: Pablo Neira Ayuso, Phil Sutter, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, netfilter-devel,
coreteam, netdev, linux-kernel, AutonomousCodeSecurity, tgopinath,
kys
In-Reply-To: <20260706232850.3333016-1-xmei5@asu.edu>
Xiang Mei (Microsoft) <xmei5@asu.edu> wrote:
> br_ip6_fragment() gets prevhdr, a pointer into the skb head, from
> ip6_find_1stfragopt(), then calls skb_checksum_help(). For a cloned skb
> skb_checksum_help() reallocates the head via pskb_expand_head(), leaving
> prevhdr dangling. It is later dereferenced in ip6_frag_next(), causing a
> use-after-free write.
>
> Re-find prevhdr after skb_checksum_help() so it points into the current
> head.
>
> BUG: KASAN: slab-use-after-free in ip6_frag_next (net/ipv6/ip6_output.c:857)
> Write of size 1 at addr ffff888013ff5016 by task exploit/141
> Call Trace:
> ...
> kasan_report (mm/kasan/report.c:595)
> ip6_frag_next (net/ipv6/ip6_output.c:857)
> br_ip6_fragment (net/ipv6/netfilter.c:212)
> nf_ct_bridge_post (net/bridge/netfilter/nf_conntrack_bridge.c:407)
> nf_hook_slow (net/netfilter/core.c:619)
> br_forward_finish (net/bridge/br_forward.c:66)
> __br_forward (net/bridge/br_forward.c:115)
> maybe_deliver (net/bridge/br_forward.c:191)
> br_flood (net/bridge/br_forward.c:245)
> br_handle_frame_finish (net/bridge/br_input.c:229)
> br_handle_frame (net/bridge/br_input.c:442)
> ...
> packet_sendmsg (net/packet/af_packet.c:3114)
> ...
> do_syscall_64 (arch/x86/entry/syscall_64.c:94)
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
> Kernel panic - not syncing: Fatal exception in interrupt
>
> Fixes: 764dd163ac92 ("netfilter: nf_conntrack_bridge: add support for IPv6")
> Reported-by: AutonomousCodeSecurity@microsoft.com
> Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
> ---
> net/ipv6/netfilter.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/ipv6/netfilter.c b/net/ipv6/netfilter.c
> index 6d80f85e55fa..547879da9532 100644
> --- a/net/ipv6/netfilter.c
> +++ b/net/ipv6/netfilter.c
> @@ -147,6 +147,10 @@ int br_ip6_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
> (err = skb_checksum_help(skb)))
> goto blackhole;
>
> + err = ip6_find_1stfragopt(skb, &prevhdr);
> + if (err < 0)
> + goto blackhole;
Would you mind sending a v2 that solves this the same way that it was
fixed in ipv6 output engine?
See
ef0efcd3bd3f ("ipv6: Fix dangling pointer when ipv6 fragment")
Thanks!
^ permalink raw reply
* [PATCH net-next 0/2] nfc: llcp: Move to .getsockopt_iter
From: Breno Leitao @ 2026-07-08 11:51 UTC (permalink / raw)
To: David Heidelberg, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: oe-linux-nfc, netdev, linux-kernel, sdf.kernel, Breno Leitao,
kernel-team
Continue to convert the protocols to getsockopt_iter callback.
Proto llcp is one of the last to be converted, and it was waiting for
the following fixes to land first, avoiding merge conflicts.
* commit 000fb5bc757a ("nfc: llcp: read llcp_sock->local under the
socket lock in getsockopt")
* commit 81e676dec04f4 ("nfc: llcp: avoid userspace overflow on invalid
optlen")
Now that they have landed, let's move llcp to .getsockopt_iter callback
Regarding the whole project migration, this is where we are:
Missing proto_ops migration (as of net-next)
net/can/isotp.c:1707 isotp_ops (.getsockopt = isotp_getsockopt) [1]
net/can/j1939/socket.c:1375 j1939_ops (.getsockopt = j1939_sk_getsockopt) [1]
net/ieee802154/socket.c:410 ieee802154_raw_ops (.getsockopt = sock_common_getsockopt)
net/ieee802154/socket.c:972 ieee802154_dgram_ops (.getsockopt = sock_common_getsockopt)
net/ipv4/af_inet.c:1060 inet_stream_ops (.getsockopt = sock_common_getsockopt)
net/ipv4/af_inet.c:1096 inet_dgram_ops (.getsockopt = sock_common_getsockopt)
net/ipv4/af_inet.c:1128 inet_sockraw_ops (.getsockopt = sock_common_getsockopt)
net/ipv6/af_inet6.c:660 inet6_stream_ops (.getsockopt = sock_common_getsockopt)
net/ipv6/af_inet6.c:696 inet6_dgram_ops (.getsockopt = sock_common_getsockopt)
net/ipv6/raw.c:1276 inet6_sockraw_ops (.getsockopt = sock_common_getsockopt)
net/l2tp/l2tp_ip.c:628 l2tp_ip_ops (.getsockopt = sock_common_getsockopt)
net/l2tp/l2tp_ip6.c:757 l2tp_ip6_ops (.getsockopt = sock_common_getsockopt)
net/mptcp/protocol.c:4567 mptcp_stream_ops (.getsockopt = sock_common_getsockopt)
net/mptcp/protocol.c:4676 mptcp_v6_stream_ops (.getsockopt = sock_common_getsockopt)
net/phonet/socket.c:451 phonet_stream_ops (.getsockopt = sock_common_getsockopt)
net/sctp/ipv6.c:1043 inet6_seqpacket_ops (.getsockopt = sock_common_getsockopt)
net/sctp/protocol.c:1106 inet_seqpacket_ops (.getsockopt = sock_common_getsockopt)
net/smc/af_smc.c:3330 smc_sock_ops (.getsockopt = smc_getsockopt)
net/smc/smc_inet.c:33 smc_inet_stream_ops (.getsockopt = smc_getsockopt)
net/smc/smc_inet.c:80 smc_inet6_stream_ops (.getsockopt = smc_getsockopt)
Link: https://lore.kernel.org/all/20260507-getsock_two_can-v1-0-3c2ae9edfadc@debian.org/ [1]
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Breno Leitao (2):
nfc: llcp: widen getsockopt value locals to u32
nfc: llcp: convert to getsockopt_iter
net/nfc/llcp_sock.c | 25 ++++++++++++-------------
1 file changed, 12 insertions(+), 13 deletions(-)
---
base-commit: 5c73cd9f0819c1c44e373e3dabb68318b1de1a12
change-id: 20260706-getsockopt_phase3-34f7b5eb3e0b
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply
* [PATCH net-next 2/2] nfc: llcp: convert to getsockopt_iter
From: Breno Leitao @ 2026-07-08 11:51 UTC (permalink / raw)
To: David Heidelberg, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: oe-linux-nfc, netdev, linux-kernel, sdf.kernel, Breno Leitao,
kernel-team
In-Reply-To: <20260708-getsockopt_phase3-v1-0-d8394f2fc554@debian.org>
Convert nfc_llcp_getsockopt() to the getsockopt_iter proto_ops callback.
It takes a sockopt_t and writes each value with copy_to_iter() instead of
a put_user() into optval; the socket layer builds the sockopt_t and copies
the length back. The socket lock and optlen validation are unchanged.
No functional change.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
net/nfc/llcp_sock.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/net/nfc/llcp_sock.c b/net/nfc/llcp_sock.c
index 94850fbe3620d..0f9cd03294074 100644
--- a/net/nfc/llcp_sock.c
+++ b/net/nfc/llcp_sock.c
@@ -302,21 +302,20 @@ static int nfc_llcp_setsockopt(struct socket *sock, int level, int optname,
}
static int nfc_llcp_getsockopt(struct socket *sock, int level, int optname,
- char __user *optval, int __user *optlen)
+ sockopt_t *opt)
{
struct nfc_llcp_local *local;
struct sock *sk = sock->sk;
struct nfc_llcp_sock *llcp_sock = nfc_llcp_sock(sk);
+ u32 miux, remote_miu, remote_lto, remote_rw, rw;
int len, err = 0;
- u32 miux, remote_miu, rw;
pr_debug("%p optname %d\n", sk, optname);
if (level != SOL_NFC)
return -ENOPROTOOPT;
- if (get_user(len, optlen))
- return -EFAULT;
+ len = opt->optlen;
if (len < 0)
return -EINVAL;
@@ -337,7 +336,7 @@ static int nfc_llcp_getsockopt(struct socket *sock, int level, int optname,
switch (optname) {
case NFC_LLCP_RW:
rw = llcp_sock->rw > LLCP_MAX_RW ? local->rw : llcp_sock->rw;
- if (put_user(rw, (u32 __user *) optval))
+ if (copy_to_iter(&rw, len, &opt->iter_out) != len)
err = -EFAULT;
break;
@@ -346,7 +345,7 @@ static int nfc_llcp_getsockopt(struct socket *sock, int level, int optname,
miux = be16_to_cpu(llcp_sock->miux) > LLCP_MAX_MIUX ?
be16_to_cpu(local->miux) : be16_to_cpu(llcp_sock->miux);
- if (put_user(miux, (u32 __user *) optval))
+ if (copy_to_iter(&miux, len, &opt->iter_out) != len)
err = -EFAULT;
break;
@@ -355,19 +354,21 @@ static int nfc_llcp_getsockopt(struct socket *sock, int level, int optname,
remote_miu = llcp_sock->remote_miu > LLCP_MAX_MIU ?
local->remote_miu : llcp_sock->remote_miu;
- if (put_user(remote_miu, (u32 __user *) optval))
+ if (copy_to_iter(&remote_miu, len, &opt->iter_out) != len)
err = -EFAULT;
break;
case NFC_LLCP_REMOTE_LTO:
- if (put_user(local->remote_lto / 10, (u32 __user *) optval))
+ remote_lto = local->remote_lto / 10;
+ if (copy_to_iter(&remote_lto, len, &opt->iter_out) != len)
err = -EFAULT;
break;
case NFC_LLCP_REMOTE_RW:
- if (put_user(llcp_sock->remote_rw, (u32 __user *) optval))
+ remote_rw = llcp_sock->remote_rw;
+ if (copy_to_iter(&remote_rw, len, &opt->iter_out) != len)
err = -EFAULT;
break;
@@ -379,8 +380,7 @@ static int nfc_llcp_getsockopt(struct socket *sock, int level, int optname,
release_sock(sk);
- if (put_user(len, optlen))
- return -EFAULT;
+ opt->optlen = len;
return err;
}
@@ -937,7 +937,7 @@ static const struct proto_ops llcp_sock_ops = {
.listen = llcp_sock_listen,
.shutdown = sock_no_shutdown,
.setsockopt = nfc_llcp_setsockopt,
- .getsockopt = nfc_llcp_getsockopt,
+ .getsockopt_iter = nfc_llcp_getsockopt,
.sendmsg = llcp_sock_sendmsg,
.recvmsg = llcp_sock_recvmsg,
.mmap = sock_no_mmap,
--
2.53.0-Meta
^ permalink raw reply related
* [PATCH net-next 1/2] nfc: llcp: widen getsockopt value locals to u32
From: Breno Leitao @ 2026-07-08 11:51 UTC (permalink / raw)
To: David Heidelberg, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: oe-linux-nfc, netdev, linux-kernel, sdf.kernel, Breno Leitao,
kernel-team
In-Reply-To: <20260708-getsockopt_phase3-v1-0-d8394f2fc554@debian.org>
nfc_llcp_getsockopt() returns each option as a u32 (written through a
(u32 __user *) cast), but the temporary variables are smaller than that,
and they are promoted at write side, example:
u8 rw;
put_user(rw, (u32 __user *) optval)
That is fine, but I want to widen the rw/miux/remote_miu locals from
u8/u16 to u32 so the following getsockopt_iter conversion can pass their
address to copy_to_iter(), which expects an object of the exact width.
No functional change.
PS: I am sending this as a separated patch to make sure this conversion
explictly reviewable.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
net/nfc/llcp_sock.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/nfc/llcp_sock.c b/net/nfc/llcp_sock.c
index 5558d8a4d48b3..94850fbe3620d 100644
--- a/net/nfc/llcp_sock.c
+++ b/net/nfc/llcp_sock.c
@@ -308,8 +308,7 @@ static int nfc_llcp_getsockopt(struct socket *sock, int level, int optname,
struct sock *sk = sock->sk;
struct nfc_llcp_sock *llcp_sock = nfc_llcp_sock(sk);
int len, err = 0;
- u16 miux, remote_miu;
- u8 rw;
+ u32 miux, remote_miu, rw;
pr_debug("%p optname %d\n", sk, optname);
--
2.53.0-Meta
^ permalink raw reply related
* RE: [PATCH v4 net-next 12/14] net: enetc: remove redundant num_vsi field from enetc_port_caps
From: Wei Fang (OSS) @ 2026-07-08 12:01 UTC (permalink / raw)
To: sashiko-reviews@lists.linux.dev
Cc: imx@lists.linux.dev, Frank.Li@kernel.org, network dev
In-Reply-To: <20260708084830.90E5E1F00A3D@smtp.kernel.org>
> > diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
> b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
> > index cab79f81d6fe0..fcfbabb29d22e 100644
> > --- a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
> > +++ b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
> [ ... ]
> > @@ -255,34 +254,35 @@ static void enetc4_default_rings_allocation(struct
> enetc_pf *pf)
> > {
> > struct enetc_hw *hw = &pf->si->hw;
> > u32 num_rx_bdr, num_tx_bdr, val;
> > + int num_vfs = pf->total_vfs;
> > u32 vf_tx_bdr, vf_rx_bdr;
> > int i, rx_rem, tx_rem;
> >
> > - if (pf->caps.num_rx_bdr < ENETC_SI_MAX_RING_NUM +
> pf->caps.num_vsi)
> > - num_rx_bdr = pf->caps.num_rx_bdr - pf->caps.num_vsi;
> > + if (pf->caps.num_rx_bdr < ENETC_SI_MAX_RING_NUM + num_vfs)
> > + num_rx_bdr = pf->caps.num_rx_bdr - num_vfs;
> > else
> > num_rx_bdr = ENETC_SI_MAX_RING_NUM;
> >
> > - if (pf->caps.num_tx_bdr < ENETC_SI_MAX_RING_NUM +
> pf->caps.num_vsi)
> > - num_tx_bdr = pf->caps.num_tx_bdr - pf->caps.num_vsi;
> > + if (pf->caps.num_tx_bdr < ENETC_SI_MAX_RING_NUM + num_vfs)
> > + num_tx_bdr = pf->caps.num_tx_bdr - num_vfs;
> > else
> > num_tx_bdr = ENETC_SI_MAX_RING_NUM;
> >
> > val = enetc4_psicfgr0_val_construct(false, num_tx_bdr, num_rx_bdr);
> > enetc_port_wr(hw, ENETC4_PSICFGR0(0), val);
> >
> > - if (!pf->caps.num_vsi)
> > + if (!num_vfs)
> > return;
>
> [Severity: High]
> In enetc4_default_rings_allocation(), when num_vfs is 0 (such as when
> CONFIG_PCI_IOV is disabled), this returns early without zeroing the ring
> allocations in the VSIs' PSICFGR0 registers.
>
> Because num_vfs is 0 instead of the true physical VSI count, the PF is
> allocated the maximum possible hardware rings.
>
> If these VSI registers retain non-zero values (e.g., from firmware defaults
> or after a warm reboot), won't the sum of configured rings across the PF and
> VSIs strictly exceed the physical hardware capacity?
>
> Could this lead to memory corruption within the ENETC device's internal
> SRAM or cause DMA issues due to overlapping BD ring structures?
The PF performs PCIe FLR when the driver probes, it will reset all the registers.
The default values of VSIs' PSICFGR0 registers are 0.
^ permalink raw reply
* Re: [PATCH net-next 3/6] net: stmmac: mediatek: rename MT2712 and MT8195 variant methods
From: Louis-Alexis Eyraud @ 2026-07-08 12:04 UTC (permalink / raw)
To: Maxime Chevallier, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Matthias Brugger,
AngeloGioacchino Del Regno, Biao Huang, Maxime Coquelin,
Alexandre Torgue
Cc: rmk+kernel, kernel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-stm32
In-Reply-To: <5dbd217b-8df5-42cd-9197-36e0fb91ffe7@bootlin.com>
Hi Maxime,
On Tue, 2026-07-07 at 11:05 +0200, Maxime Chevallier wrote:
>
>
> On 7/7/26 10:21, Louis-Alexis Eyraud wrote:
> > In preparation of newer SoC support, rename MT2712 and MT8195
> > variant
> > methods and sub functions to more generic names.
> >
> > Signed-off-by: Louis-Alexis Eyraud
> > <louisalexis.eyraud@collabora.com>
> > ---
> > .../net/ethernet/stmicro/stmmac/dwmac-mediatek.c | 32
> > +++++++++++-----------
> > 1 file changed, 16 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> > b/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> > index 0cabab4fd89a..28e87990b0a1 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> > @@ -110,7 +110,7 @@ static const char * const mt8195_dwmac_clk_l[]
> > = {
> > "axi", "apb", "mac_cg", "mac_main", "ptp_ref"
> > };
> >
> > -static int mt2712_set_interface(struct mediatek_dwmac_plat_data
> > *plat,
> > +static int set_phy_interface_v1(struct mediatek_dwmac_plat_data
> > *plat,
> > u8 phy_intf_sel)
>
> What does this naming of "v1 / v2" refer to ?
>
> I personally don't find it much better than the current one prefixed
> by the SoC
> name. You still end-up using registers that have the "MT8195_" prefix
> in their
> names in the 'v2' variants of these functions, so it still sound SoC-
> family specific :)
>
I agree.
In a work in progress version of this series, I had renamed all
register definitions as well (to remove the mt8195_ prefix) but dropped
the changes because too much difference for little gain.
I kept this patch but it does not really improve the code.
> I'd say you can keep the original names as-is, or if you really want
> a rename,
> maybe use the mt81xx_ prefix for MT8195 and MT8189 ?
I'll drop this patch in v2 to keep the existing names (and smaller
changes).
Regards,
Louis-Alexis
> Maxime
^ permalink raw reply
* [PATCH net] rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled
From: Ilia Gavrilov @ 2026-07-08 11:59 UTC (permalink / raw)
To: Allison Henderson
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Ka-Cheong Poon, Santosh Shilimkar,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
rds-devel@oss.oracle.com, linux-kernel@vger.kernel.org,
lvc-project@linuxtesting.org
When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst
is never initialized because inet6_init() exits before addrconf_init()
is called to initialize it. An attempt to bind an RDS socket to
an ipv6 address results in a crash in __ipv6_chk_addr_and_flags()
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0
Call Trace:
<TASK>
ipv6_chk_addr+0x3b/0x50
rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp]
rds_trans_get_preferred+0x15d/0x2d0 [rds]
? trace_hardirqs_on+0x2d/0x110
rds_bind+0x1433/0x1d60 [rds]
? rds_remove_bound+0xd50/0xd50 [rds]
? aa_af_perm+0x250/0x250
? __might_fault+0xde/0x190
? __sys_bind+0x1dc/0x210
__sys_bind+0x1dc/0x210
? __ia32_sys_socketpair+0x100/0x100
? restore_fpregs_from_fpstate+0x53/0x100
__x64_sys_bind+0x73/0xb0
? syscall_enter_from_user_mode+0x1c/0x50
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
RIP: 0033:0x7f47f8269ea9
</TASK>
The following code reproduces the issue:
struct sockaddr_in6 addr;
s = socket(PF_RDS, SOCK_SEQPACKET, 0);
memset(&addr, 0, sizeof(addr));
inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr);
addr.sin6_family = AF_INET6;
addr.sin6_port = htons(PORT);
bind(s, &addr, sizeof(addr);
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with Syzkaller.
Fixes: eee2fa6ab322 ("rds: Changing IP address internal representation to struct in6_addr")
Fixes: 1e2b44e78eea ("rds: Enable RDS IPv6 support")
Signed-off-by: Ilia Gavrilov <Ilia.Gavrilov@infotecs.ru>
---
net/rds/ib.c | 4 ++++
net/rds/tcp.c | 8 +++++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/rds/ib.c b/net/rds/ib.c
index 39f87272e071..8f9cf491984f 100644
--- a/net/rds/ib.c
+++ b/net/rds/ib.c
@@ -429,6 +429,10 @@ static int rds_ib_laddr_check_cm(struct net *net, const struct in6_addr *addr,
sa = (struct sockaddr *)&sin;
} else {
#if IS_ENABLED(CONFIG_IPV6)
+ if (!ipv6_mod_enabled()) {
+ ret = -EADDRNOTAVAIL;
+ goto out;
+ }
memset(&sin6, 0, sizeof(sin6));
sin6.sin6_family = AF_INET6;
sin6.sin6_addr = *addr;
diff --git a/net/rds/tcp.c b/net/rds/tcp.c
index a1de114d5e2e..955d92277d5a 100644
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -366,9 +366,11 @@ int rds_tcp_laddr_check(struct net *net, const struct in6_addr *addr,
rcu_read_unlock();
}
#if IS_ENABLED(CONFIG_IPV6)
- ret = ipv6_chk_addr(net, addr, dev, 0);
- if (ret)
- return 0;
+ if (ipv6_mod_enabled()) {
+ ret = ipv6_chk_addr(net, addr, dev, 0);
+ if (ret)
+ return 0;
+ }
#endif
return -EADDRNOTAVAIL;
}
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v3 0/2] bridge: mcast: Fix a false positive lockdep splat
From: Ido Schimmel @ 2026-07-08 12:28 UTC (permalink / raw)
To: netdev, bridge
Cc: davem, kuba, pabeni, edumazet, horms, razor, petrm, Ido Schimmel
Patch #1 fixes false positive lockdep splat. See the commit message for
more details.
Patch #2 is small cleanup following the previous patch.
Targeting at net-next since this is a false positive that is only
visible with lockdep enabled and the change is not small / trivial.
v3:
- Use skb_queue_splice_tail_init() (Eric).
- Increment multicast stats from the workqueue.
- Add patch #2.
- Target at net-next.
v2: https://lore.kernel.org/netdev/20260430162604.1043756-1-idosch@nvidia.com/
- Limit the queue to 1,000 skbs.
- Edit the trace to avoid checkpatch errors.
v1: https://lore.kernel.org/netdev/20260426133435.207006-1-idosch@nvidia.com/
Ido Schimmel (2):
bridge: mcast: Fix a false positive lockdep splat
bridge: mcast: Remove unnecessary argument from
br_multicast_alloc_query()
net/bridge/br_multicast.c | 105 ++++++++++++++++++++++++++++++--------
net/bridge/br_private.h | 4 ++
2 files changed, 89 insertions(+), 20 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH net-next v3 1/2] bridge: mcast: Fix a false positive lockdep splat
From: Ido Schimmel @ 2026-07-08 12:28 UTC (permalink / raw)
To: netdev, bridge
Cc: davem, kuba, pabeni, edumazet, horms, razor, petrm, Ido Schimmel
In-Reply-To: <20260708122820.1298718-1-idosch@nvidia.com>
Connecting two bridges on the same system [1] can result in a lockdep
splat [2].
The report is a false positive. Multicast queries are built and
transmitted under the bridge multicast lock. When the outgoing port of
one bridge is configured on top of another bridge, the transmit path
re-enters bridge code and acquires the other bridge's multicast lock in
order to snoop the query. Both lock instances share a single lockdep
class, so lockdep flags the nested acquisition as an AA deadlock.
Giving each bridge its own lock class will not solve the problem: the
reverse topology would produce an ABBA splat with the same pair of
classes. It also consumes a lockdep key per bridge.
Instead, fix the problem by deferring the transmission of the queries to
a workqueue. Build the skb and update querier state under the lock as
before, then enqueue the skb on a per multicast context queue and
schedule the work.
Purge the queue when the multicast context is de-initialized. At this
stage the work cannot be requeued. There is no need to take a reference
on skb->dev since the work cannot outlive the bridge or the bridge port.
Use the high priority workqueue to reduce the delay between the enqueue
time and the transmission time. With default settings (i.e., querier
interval - 255 seconds, query interval - 125 seconds) the extra delay
should not be a problem.
Avoid the unlikely case of the queue growing endlessly by limiting it to
1,000 skbs. Use this number for the simple reason that this is the
default Tx queue length.
Use local_bh_{disable,enable}() to disable/enable softIRQs and migration
in order to avoid corrupting the multicast statistics (per-CPU
u64_stats).
[1]
ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1
ip link add name br0 up type bridge mcast_snooping 1 mcast_querier 1
ip link add link br0 name br0.10 up master br1 type vlan id 10
[2]
WARNING: possible recursive locking detected
7.0.0-virtme-gb50c64a58a90 #1 Not tainted
[...]
ip/339 is trying to acquire lock:
ffff888104f0b480 (&br->multicast_lock){+.-.}-{3:3}, at: br_ip6_multicast_query (net/bridge/br_multicast.c:3584)
but task is already holding lock:
ffff888104f03480 (&br->multicast_lock){+.-.}-{3:3}, at: br_multicast_port_query_expired (net/bridge/br_multicast.c:1904)
[...]
Call Trace:
[...]
br_ip6_multicast_query (net/bridge/br_multicast.c:3584)
br_multicast_ipv6_rcv (net/bridge/br_multicast.c:3988)
br_dev_xmit (net/bridge/br_device.c:98 (discriminator 1))
dev_hard_start_xmit (net/core/dev.c:3904)
__dev_queue_xmit (net/core/dev.c:4871)
vlan_dev_hard_start_xmit (net/8021q/vlan_dev.c:131 (discriminator 1))
dev_hard_start_xmit (net/core/dev.c:3904)
__dev_queue_xmit (net/core/dev.c:4871)
br_dev_queue_push_xmit (net/bridge/br_forward.c:60)
__br_multicast_send_query (net/bridge/br_multicast.c:1811 (discriminator 1))
br_multicast_send_query (net/bridge/br_multicast.c:1889)
br_multicast_port_query_expired (net/bridge/br_multicast.c:1914)
call_timer_fn (kernel/time/timer.c:1749)
[...]
Reported-by: syzbot+d7b7f1412c02134efa6d@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/000000000000c4c9d405f2643e01@google.com/
Reviewed-by: Petr Machata <petrm@nvidia.com>
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
net/bridge/br_multicast.c | 87 +++++++++++++++++++++++++++++++++++----
net/bridge/br_private.h | 4 ++
2 files changed, 83 insertions(+), 8 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 6b3ac473fd22..e39494b26ab1 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1774,6 +1774,64 @@ static void br_multicast_select_own_querier(struct net_bridge_mcast *brmctx,
#endif
}
+static u8 br_multicast_query_type(const struct sk_buff *skb)
+{
+ return skb->protocol == htons(ETH_P_IP) ? IGMP_HOST_MEMBERSHIP_QUERY :
+ ICMPV6_MGM_QUERY;
+}
+
+static void br_multicast_port_query_queue_work(struct work_struct *work)
+{
+ struct net_bridge_mcast_port *pmctx;
+ struct sk_buff_head list;
+ struct sk_buff *skb;
+
+ pmctx = container_of(work, struct net_bridge_mcast_port,
+ query_queue_work);
+
+ __skb_queue_head_init(&list);
+ spin_lock_bh(&pmctx->query_queue.lock);
+ skb_queue_splice_tail_init(&pmctx->query_queue, &list);
+ spin_unlock_bh(&pmctx->query_queue.lock);
+
+ while ((skb = __skb_dequeue(&list))) {
+ u8 query_type = br_multicast_query_type(skb);
+
+ local_bh_disable();
+ br_multicast_count(pmctx->port->br, pmctx->port, skb,
+ query_type, BR_MCAST_DIR_TX);
+ NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_OUT, dev_net(skb->dev),
+ NULL, skb, NULL, skb->dev, br_dev_queue_push_xmit);
+ local_bh_enable();
+ }
+}
+
+static void br_multicast_query_queue_work(struct work_struct *work)
+{
+ struct net_bridge_mcast *brmctx;
+ struct sk_buff_head list;
+ struct sk_buff *skb;
+
+ brmctx = container_of(work, struct net_bridge_mcast, query_queue_work);
+
+ __skb_queue_head_init(&list);
+ spin_lock_bh(&brmctx->query_queue.lock);
+ skb_queue_splice_tail_init(&brmctx->query_queue, &list);
+ spin_unlock_bh(&brmctx->query_queue.lock);
+
+ while ((skb = __skb_dequeue(&list))) {
+ u8 query_type = br_multicast_query_type(skb);
+
+ local_bh_disable();
+ br_multicast_count(brmctx->br, NULL, skb, query_type,
+ BR_MCAST_DIR_RX);
+ netif_rx(skb);
+ local_bh_enable();
+ }
+}
+
+#define BR_MULTICAST_QUERY_QUEUE_LEN_MAX 1000
+
static void __br_multicast_send_query(struct net_bridge_mcast *brmctx,
struct net_bridge_mcast_port *pmctx,
struct net_bridge_port_group *pg,
@@ -1783,6 +1841,7 @@ static void __br_multicast_send_query(struct net_bridge_mcast *brmctx,
u8 sflag,
bool *need_rexmit)
{
+ struct sk_buff_head *queue;
bool over_lmqt = !!sflag;
struct sk_buff *skb;
u8 igmp_type;
@@ -1791,7 +1850,12 @@ static void __br_multicast_send_query(struct net_bridge_mcast *brmctx,
!br_multicast_ctx_matches_vlan_snooping(brmctx))
return;
+ queue = pmctx ? &pmctx->query_queue : &brmctx->query_queue;
+
again_under_lmqt:
+ if (skb_queue_len_lockless(queue) >= BR_MULTICAST_QUERY_QUEUE_LEN_MAX)
+ return;
+
skb = br_multicast_alloc_query(brmctx, pmctx, pg, ip_dst, group,
with_srcs, over_lmqt, sflag, &igmp_type,
need_rexmit);
@@ -1800,11 +1864,8 @@ static void __br_multicast_send_query(struct net_bridge_mcast *brmctx,
if (pmctx) {
skb->dev = pmctx->port->dev;
- br_multicast_count(brmctx->br, pmctx->port, skb, igmp_type,
- BR_MCAST_DIR_TX);
- NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_OUT,
- dev_net(pmctx->port->dev), NULL, skb, NULL, skb->dev,
- br_dev_queue_push_xmit);
+ skb_queue_tail(queue, skb);
+ queue_work(system_highpri_wq, &pmctx->query_queue_work);
if (over_lmqt && with_srcs && sflag) {
over_lmqt = false;
@@ -1812,9 +1873,8 @@ static void __br_multicast_send_query(struct net_bridge_mcast *brmctx,
}
} else {
br_multicast_select_own_querier(brmctx, group, skb);
- br_multicast_count(brmctx->br, NULL, skb, igmp_type,
- BR_MCAST_DIR_RX);
- netif_rx(skb);
+ skb_queue_tail(queue, skb);
+ queue_work(system_highpri_wq, &brmctx->query_queue_work);
}
}
@@ -1997,6 +2057,10 @@ void br_multicast_port_ctx_init(struct net_bridge_port *port,
pmctx->port = port;
pmctx->vlan = vlan;
pmctx->multicast_router = MDB_RTR_TYPE_TEMP_QUERY;
+
+ skb_queue_head_init(&pmctx->query_queue);
+ INIT_WORK(&pmctx->query_queue_work, br_multicast_port_query_queue_work);
+
timer_setup(&pmctx->ip4_mc_router_timer,
br_ip4_multicast_router_expired, 0);
timer_setup(&pmctx->ip4_own_query.timer,
@@ -2038,6 +2102,8 @@ void br_multicast_port_ctx_deinit(struct net_bridge_mcast_port *pmctx)
del |= br_ip4_multicast_rport_del(pmctx);
br_multicast_rport_del_notify(pmctx, del);
spin_unlock_bh(&br->multicast_lock);
+ cancel_work_sync(&pmctx->query_queue_work);
+ __skb_queue_purge(&pmctx->query_queue);
}
int br_multicast_add_port(struct net_bridge_port *port)
@@ -4112,6 +4178,9 @@ void br_multicast_ctx_init(struct net_bridge *br,
seqcount_spinlock_init(&brmctx->ip6_querier.seq, &br->multicast_lock);
#endif
+ skb_queue_head_init(&brmctx->query_queue);
+ INIT_WORK(&brmctx->query_queue_work, br_multicast_query_queue_work);
+
timer_setup(&brmctx->ip4_mc_router_timer,
br_ip4_multicast_local_router_expired, 0);
timer_setup(&brmctx->ip4_other_query.timer,
@@ -4135,6 +4204,8 @@ void br_multicast_ctx_init(struct net_bridge *br,
void br_multicast_ctx_deinit(struct net_bridge_mcast *brmctx)
{
__br_multicast_stop(brmctx);
+ cancel_work_sync(&brmctx->query_queue_work);
+ __skb_queue_purge(&brmctx->query_queue);
}
void br_multicast_init(struct net_bridge *br)
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index d55ea9516e3e..f8f77a2d4891 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -131,6 +131,8 @@ struct net_bridge_mcast_port {
unsigned char multicast_router;
u32 mdb_n_entries;
u32 mdb_max_entries;
+ struct sk_buff_head query_queue;
+ struct work_struct query_queue_work;
#endif /* CONFIG_BRIDGE_IGMP_SNOOPING */
};
@@ -167,6 +169,8 @@ struct net_bridge_mcast {
struct bridge_mcast_own_query ip6_own_query;
struct bridge_mcast_querier ip6_querier;
#endif /* IS_ENABLED(CONFIG_IPV6) */
+ struct sk_buff_head query_queue;
+ struct work_struct query_queue_work;
#endif /* CONFIG_BRIDGE_IGMP_SNOOPING */
};
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net-next 5/6] net: stmmac: mediatek: add support for TX deallocation adjustment feature
From: Louis-Alexis Eyraud @ 2026-07-08 12:28 UTC (permalink / raw)
To: Maxime Chevallier, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Matthias Brugger,
AngeloGioacchino Del Regno, Biao Huang, Maxime Coquelin,
Alexandre Torgue
Cc: rmk+kernel, kernel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-stm32
In-Reply-To: <2a421449-01eb-4066-8c19-d554ff8e4f6e@bootlin.com>
Hi Maxime,
On Tue, 2026-07-07 at 11:11 +0200, Maxime Chevallier wrote:
> Hi,
>
> On 7/7/26 10:21, Louis-Alexis Eyraud wrote:
> > The MT8189 SoC has in the Ethernet control 0 register from the
> > peripheral configuration (pericfg) additional bits to adjust the TX
> > deallocation.
> >
> > In preparation of MT8189 SoC support, add its definition, use in
> > the
> > set_delay_v2 callback, and a support flag in the platform data.
>
> Can you elaborate a bit on this ? I don't quite get what you mean by
> "tx deallocation", this seems to have to do with RGMII timings from
> the register access pattern, but the local boolean flag for the
> feature
> is named "use_stage_fine", I'm failing to connect all the dots here
> with the different terminology in use :(
>
The data sheets I have, don't have info regarding this register, so
I'll try to get more and improve commit and/or code description.
I'll also check if the register definition name is consistent
(downstream driver and upstream u-boot use this stage fine term).
The use_stage_fine feature flag could be renamed anyway to match what
it does.
> >
> > Signed-off-by: Louis-Alexis Eyraud
> > <louisalexis.eyraud@collabora.com>
> > ---
> > .../net/ethernet/stmicro/stmmac/dwmac-mediatek.c | 25
> > ++++++++++++++++------
> > 1 file changed, 19 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> > b/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> > index bcc0baef3f71..6b0a42b5839f 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> > @@ -37,7 +37,8 @@
> > #define ETH_FINE_DLY_RXC BIT(0)
> >
> > /* Peri Configuration register for mt8189 */
> > -#define MT8189_CTRL0_TXC_OUT_OP BIT(20)
> > +#define MT8189_CTRL0_TXC_OUT_OP BIT(20)
>
> Extra whitespace inserted here :)
>
Oops, to be fixed in v2
Regards,
Louis-Alexis
> Thanks,
>
> Maxime
^ permalink raw reply
* [PATCH net-next v3 2/2] bridge: mcast: Remove unnecessary argument from br_multicast_alloc_query()
From: Ido Schimmel @ 2026-07-08 12:28 UTC (permalink / raw)
To: netdev, bridge
Cc: davem, kuba, pabeni, edumazet, horms, razor, petrm, Ido Schimmel
In-Reply-To: <20260708122820.1298718-1-idosch@nvidia.com>
After the previous patch, __br_multicast_send_query() no longer relies
on br_multicast_alloc_query() to determine the IGMP type of the query.
Remove the argument.
Reviewed-by: Petr Machata <petrm@nvidia.com>
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
net/bridge/br_multicast.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index e39494b26ab1..f112fbb374c0 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -926,7 +926,7 @@ static struct sk_buff *br_ip4_multicast_alloc_query(struct net_bridge_mcast *brm
struct net_bridge_port_group *pg,
__be32 ip_dst, __be32 group,
bool with_srcs, bool over_lmqt,
- u8 sflag, u8 *igmp_type,
+ u8 sflag,
bool *need_rexmit)
{
struct net_bridge_port *p = pg ? pg->key.port : NULL;
@@ -1006,7 +1006,6 @@ static struct sk_buff *br_ip4_multicast_alloc_query(struct net_bridge_mcast *brm
skb_set_transport_header(skb, skb->len);
mrt = group ? brmctx->multicast_last_member_interval :
brmctx->multicast_query_response_interval;
- *igmp_type = IGMP_HOST_MEMBERSHIP_QUERY;
switch (brmctx->multicast_igmp_version) {
case 2:
@@ -1072,7 +1071,7 @@ static struct sk_buff *br_ip6_multicast_alloc_query(struct net_bridge_mcast *brm
const struct in6_addr *ip6_dst,
const struct in6_addr *group,
bool with_srcs, bool over_llqt,
- u8 sflag, u8 *igmp_type,
+ u8 sflag,
bool *need_rexmit)
{
struct net_bridge_port *p = pg ? pg->key.port : NULL;
@@ -1166,7 +1165,6 @@ static struct sk_buff *br_ip6_multicast_alloc_query(struct net_bridge_mcast *brm
interval = ipv6_addr_any(group) ?
brmctx->multicast_query_response_interval :
brmctx->multicast_last_member_interval;
- *igmp_type = ICMPV6_MGM_QUERY;
switch (brmctx->multicast_mld_version) {
case 1:
mldq = (struct mld_msg *)icmp6_hdr(skb);
@@ -1237,8 +1235,7 @@ static struct sk_buff *br_multicast_alloc_query(struct net_bridge_mcast *brmctx,
struct br_ip *ip_dst,
struct br_ip *group,
bool with_srcs, bool over_lmqt,
- u8 sflag, u8 *igmp_type,
- bool *need_rexmit)
+ u8 sflag, bool *need_rexmit)
{
__be32 ip4_dst;
@@ -1248,8 +1245,7 @@ static struct sk_buff *br_multicast_alloc_query(struct net_bridge_mcast *brmctx,
return br_ip4_multicast_alloc_query(brmctx, pmctx, pg,
ip4_dst, group->dst.ip4,
with_srcs, over_lmqt,
- sflag, igmp_type,
- need_rexmit);
+ sflag, need_rexmit);
#if IS_ENABLED(CONFIG_IPV6)
case htons(ETH_P_IPV6): {
struct in6_addr ip6_dst;
@@ -1263,8 +1259,7 @@ static struct sk_buff *br_multicast_alloc_query(struct net_bridge_mcast *brmctx,
return br_ip6_multicast_alloc_query(brmctx, pmctx, pg,
&ip6_dst, &group->dst.ip6,
with_srcs, over_lmqt,
- sflag, igmp_type,
- need_rexmit);
+ sflag, need_rexmit);
}
#endif
}
@@ -1844,7 +1839,6 @@ static void __br_multicast_send_query(struct net_bridge_mcast *brmctx,
struct sk_buff_head *queue;
bool over_lmqt = !!sflag;
struct sk_buff *skb;
- u8 igmp_type;
if (!br_multicast_ctx_should_use(brmctx, pmctx) ||
!br_multicast_ctx_matches_vlan_snooping(brmctx))
@@ -1857,7 +1851,7 @@ static void __br_multicast_send_query(struct net_bridge_mcast *brmctx,
return;
skb = br_multicast_alloc_query(brmctx, pmctx, pg, ip_dst, group,
- with_srcs, over_lmqt, sflag, &igmp_type,
+ with_srcs, over_lmqt, sflag,
need_rexmit);
if (!skb)
return;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net-next 00/15] net/mlx5e: PSP cleanups and improvements
From: Cosmin Ratiu @ 2026-07-08 12:37 UTC (permalink / raw)
To: andrew+netdev@lunn.ch, davem@davemloft.net, Tariq Toukan,
pabeni@redhat.com, netdev@vger.kernel.org, edumazet@google.com,
daniel.zahka@gmail.com, kuba@kernel.org
Cc: Boris Pismenny, willemdebruijn.kernel@gmail.com, Jianbo Liu,
leon@kernel.org, Rahul Rameshbabu, linux-kernel@vger.kernel.org,
linux-rdma@vger.kernel.org, Raed Salem, Chris Mi, Dragos Tatulea,
sdf.kernel@gmail.com, Mark Bloch, sdf@fomichev.me, Saeed Mahameed,
aleksandr.loktionov@intel.com, Gal Pressman, Lama Kayal,
jacob.e.keller@intel.com
In-Reply-To: <0dfe5f6b-dbc8-4104-8883-e88e8e59ab58@gmail.com>
On Tue, 2026-07-07 at 14:29 -0400, Daniel Zahka wrote:
>
> On 7/7/26 9:08 AM, Tariq Toukan wrote:
> > Hi,
> >
> > This series by Cosmin refactors mlx5 PSP support in preparation for
> > HW-GRO support.
> > There are almost no functionality changes in all but the last two
> > patches, which address a long-standing TODO in
> > mlx5e_psp_set_config().
> >
> > Regards,
> > Tariq
> >
> > Cosmin Ratiu (15):
> > net/mlx5e: psp: Rename the saved psp_dev to 'psd'
> > net/mlx5e: psp: Remove PSP steering mutexes
> > net/mlx5e: psp: Remove unneeded ref counting for PSP steering
> > net/mlx5e: psp: Merge rx_err rule add/delete with ft
> > create/delete
> > net/mlx5e: psp: Use helpers for steering object manipulation
> > net/mlx5e: psp: Factor out drop rule creation code
> > net/mlx5e: psp: Remove unused PSP syndrome copy action
> > net/mlx5e: psp: Rename and consolidate steering functions
> > net/mlx5e: psp: Adjust rx_check FT size and use a drop_group
> > net/mlx5e: psp: Add an RX steering table
> > net/mlx5e: psp: Use a single rx_check table
> > net/mlx5e: psp: Flatten steering structures
> > net/mlx5e: psp: Make PSP steering config dynamic
> > net/mlx5e: Return errors from profile->enable
> > net/mlx5e: psp: Report PSP dev registration errors
> >
> > drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +-
> > .../net/ethernet/mellanox/mlx5/core/en/fs.h | 7 +-
> > .../mellanox/mlx5/core/en_accel/en_accel.h | 19 +-
> > .../mellanox/mlx5/core/en_accel/psp.c | 1007 ++++++++----
> > -----
> > .../mellanox/mlx5/core/en_accel/psp.h | 18 +-
> > .../mellanox/mlx5/core/en_accel/psp_rxtx.c | 13 +-
> > .../mellanox/mlx5/core/en_accel/psp_rxtx.h | 3 +-
> > .../net/ethernet/mellanox/mlx5/core/en_main.c | 23 +-
> > .../net/ethernet/mellanox/mlx5/core/en_rep.c | 8 +-
> > 9 files changed, 516 insertions(+), 584 deletions(-)
> >
> >
> > base-commit: 31816fc5d9acf8cdf226cdd0dc296e8cf15cc033
>
> Thanks. Excited about the support for mlx5e_psp_set_config(). Jakub
> and
> I had a test case for psp_dev_ops::set_config() that we were waiting
> to
> upstream. I just rebased it onto net-next here:
> https://github.com/danieldzahka/linux/commit/b58e9a99573cf6b884e5fe3227c9af7a1f0d80b0
>
> I ran it with the series but am seeing an error trying to catch
> undecrypted PSP-UDP packets after disabling all versions with
> set_config()
>
> TAP version 13
> 1..30
> ok 1 psp.data_basic_send.v0_ip4 # SKIP Test requires IPv4
> connectivity
> ok 2 psp.data_basic_send.v0_ip6
> ok 3 psp.data_basic_send.v1_ip4 # SKIP Test requires IPv4
> connectivity
> ok 4 psp.data_basic_send.v1_ip6
> ok 5 psp.data_basic_send.v2_ip4 # SKIP Test requires IPv4
> connectivity
> ok 6 psp.data_basic_send.v2_ip6 # SKIP ('PSP version not supported',
> 'hdr0-aes-gmac-128')
> ok 7 psp.data_basic_send.v3_ip4 # SKIP Test requires IPv4
> connectivity
> ok 8 psp.data_basic_send.v3_ip6 # SKIP ('PSP version not supported',
> 'hdr0-aes-gmac-256')
> ok 9 psp.data_mss_adjust.ip4 # SKIP Test requires IPv4 connectivity
> ok 10 psp.data_mss_adjust.ip6
> ok 11 psp.data_send_off.ip4 # SKIP Test requires IPv4 connectivity
> # Exception| Traceback (most recent call last):
> # Exception| File "/root/ksft-psp-set-config/net/lib/py/ksft.py",
> line
> 420, in ksft_run
> # Exception| func(*args)
> # Exception| File "/root/./ksft-psp-set-config/drivers/net/psp.py",
> line 608, in data_send_off
> # Exception| udps.recv(8192, socket.MSG_DONTWAIT)
> # Exception| BlockingIOError: [Errno 11] Resource temporarily
> unavailable
> # Exception|
> not ok 12 psp.data_send_off.ip6
> ok 13 psp.dev_list_devices
> ok 14 psp.dev_get_device
> ok 15 psp.dev_get_device_bad
> ok 16 psp.dev_rotate
> ok 17 psp.dev_rotate_spi
> ok 18 psp.assoc_basic
> ok 19 psp.assoc_bad_dev
> ok 20 psp.assoc_sk_only_conn
> ok 21 psp.assoc_sk_only_mismatch
> ok 22 psp.assoc_sk_only_mismatch_tx
> ok 23 psp.assoc_sk_only_unconn
> ok 24 psp.assoc_version_mismatch
> ok 25 psp.assoc_twice
> ok 26 psp.data_send_bad_key
> ok 27 psp.data_send_disconnect
> ok 28 psp.data_stale_key
> ok 29 psp.removal_device_rx # XFAIL Test only works on netdevsim
> ok 30 psp.removal_device_bi # XFAIL Test only works on netdevsim
> # Totals: pass:19 fail:1 xfail:2 xpass:0 skip:8 error:0
> #
> # Responder logs (0):
> # STDERR:
> # # Set PSP enable on device 1 to 0x3
> # # Set PSP enable on device 1 to 0x0
>
> I recall this working on an earlier prototype of this feature for
> mlx5.
> Are the steering rules setup to drop PSP-UDP packets when the
> corresponding psp version is disabled?
>
We don't have per-psp version steering rules. If either version is
requested, steering rules are configured. When all versions are
disabled, steering rules are removed.
With no steering rules installed, UDP traffic should not be affected.
I will take the test and debug what's going on, and get back to you.
Cosmin.
^ permalink raw reply
* Re: [PATCH net-next 00/11][pull request] Intel Wired LAN Driver Updates 2026-07-01 (igc, igb)
From: patchwork-bot+netdevbpf @ 2026-07-08 12:40 UTC (permalink / raw)
To: Tony Nguyen; +Cc: davem, kuba, pabeni, edumazet, andrew+netdev, netdev, horms
In-Reply-To: <20260701210303.1745310-1-anthony.l.nguyen@intel.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Tony Nguyen <anthony.l.nguyen@intel.com>:
On Wed, 1 Jul 2026 14:02:49 -0700 you wrote:
> Kohei Enju adds ethtool support for get/set hash key on igc and adds
> setting of skb hash type based on values from Rx descriptor on igb.
>
> Takashi Kozu adds ethtool support for get/set hash key on igb.
>
> Faizal adds support for forcing link speed via ethtool when
> autonegotiation is disabled on the igc driver.
>
> [...]
Here is the summary with links:
- [net-next,01/11] igc: prepare for RSS key get/set support
https://git.kernel.org/netdev/net-next/c/66731a51b1fb
- [net-next,02/11] igc: expose RSS key via ethtool get_rxfh
https://git.kernel.org/netdev/net-next/c/f243be8edeab
- [net-next,03/11] igc: allow configuring RSS key via ethtool set_rxfh
https://git.kernel.org/netdev/net-next/c/3fc4c1ee5f84
- [net-next,04/11] igb: prepare for RSS key get/set support
https://git.kernel.org/netdev/net-next/c/dfaf57ef99cf
- [net-next,05/11] igb: expose RSS key via ethtool get_rxfh
https://git.kernel.org/netdev/net-next/c/1ae67b2b28bc
- [net-next,06/11] igb: allow configuring RSS key via ethtool set_rxfh
https://git.kernel.org/netdev/net-next/c/e3c94e9782a7
- [net-next,07/11] igb: set skb hash type from RSS_TYPE
https://git.kernel.org/netdev/net-next/c/17cd41a9733d
- [net-next,08/11] igc: remove unused autoneg_failed field
https://git.kernel.org/netdev/net-next/c/1ee93ee2e085
- [net-next,09/11] igc: move autoneg-enabled settings into igc_handle_autoneg_enabled()
https://git.kernel.org/netdev/net-next/c/c731361cfef9
- [net-next,10/11] igc: replace goto out with direct returns in igc_config_fc_after_link_up()
https://git.kernel.org/netdev/net-next/c/fa7315482f58
- [net-next,11/11] igc: add support for forcing link speed without autonegotiation
https://git.kernel.org/netdev/net-next/c/acb138b8235c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH net-next 0/3] mlxsw: Make the driver ops-locked
From: Ido Schimmel @ 2026-07-08 12:39 UTC (permalink / raw)
To: netdev; +Cc: davem, kuba, pabeni, edumazet, petrm, andrew+netdev, Ido Schimmel
Make the driver ops-locked in order to allow ethtool operations to be
invoked without RTNL being held.
An ops-locked driver has most of its NDOs, all of its ethtool operations
and some net device notifications run with the netdev instance lock
held.
In the specific case of mlxsw, the driver is not using any functions
that acquire this lock nor functions that expect the lock to be held for
an ops-locked driver. Therefore, converting its NDOs to run with the
lock being held is trivial except for a small quirk which is handled in
patch #1.
The driver does not generate any net device notifications, so there is
no risk of nested notifications of the ops-locked types. For the
notifications that run under the instance lock, RTNL is also held, and
the driver does not acquire the instance lock itself, so no changes are
required in its notifier handling.
Ethtool operations can be invoked without RTNL except for two operations
that are annotated in patch #2.
Lastly, patch #3 converts the driver to be ops-locked.
A probe on rtnl_lock() shows it is no longer taken when dumping
statistics:
# perf probe --add rtnl_lock
Before:
# perf stat -e probe:rtnl_lock -- ethtool -S swp1 --all-groups
[...]
1 probe:rtnl_lock
After:
# perf stat -e probe:rtnl_lock -- ethtool -S swp1 --all-groups
[...]
0 probe:rtnl_lock
No issues were reported after running a full regression with a debug
config that has lockdep enabled.
Ido Schimmel (3):
mlxsw: Convert to async version of ndo_set_rx_mode
mlxsw: ethtool: Prepare for RTNL-less ethtool operations
mlxsw: Tell the core to use the netdev instance lock
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 8 ++++++--
drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c | 2 ++
2 files changed, 8 insertions(+), 2 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH net-next 1/3] mlxsw: Convert to async version of ndo_set_rx_mode
From: Ido Schimmel @ 2026-07-08 12:39 UTC (permalink / raw)
To: netdev; +Cc: davem, kuba, pabeni, edumazet, petrm, andrew+netdev, Ido Schimmel
In-Reply-To: <20260708123933.1303291-1-idosch@nvidia.com>
Commit c5b9b518adab ("mlxsw: spectrum: Add set_rx_mode ndo stub") added
a stub for ndo_set_rx_mode to prevent dev_ifsioc() from returning an
error for the SIOCADDMULTI and SIOCDELMULTI cases.
Since then dev_ifsioc() was taught to also accept ndo_set_rx_mode_async
and commit 3cbd22938877 ("net: warn ops-locked drivers still using
ndo_set_rx_mode") modified register_netdevice() to warn when registering
an ops-locked net device that still uses ndo_set_rx_mode instead of
ndo_set_rx_mode_async.
In preparation for converting the driver to be ops-locked, convert the
ndo_set_rx_mode stub to a ndo_set_rx_mode_async stub.
Reviewed-by: Danielle Ratson <danieller@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 82569162d2e5..3ee1272dcf0e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -663,8 +663,11 @@ static netdev_tx_t mlxsw_sp_port_xmit(struct sk_buff *skb,
return NETDEV_TX_OK;
}
-static void mlxsw_sp_set_rx_mode(struct net_device *dev)
+static int mlxsw_sp_set_rx_mode_async(struct net_device *dev,
+ struct netdev_hw_addr_list *uc,
+ struct netdev_hw_addr_list *mc)
{
+ return 0;
}
static int mlxsw_sp_port_set_mac_address(struct net_device *dev, void *p)
@@ -1191,7 +1194,7 @@ static const struct net_device_ops mlxsw_sp_port_netdev_ops = {
.ndo_stop = mlxsw_sp_port_stop,
.ndo_start_xmit = mlxsw_sp_port_xmit,
.ndo_setup_tc = mlxsw_sp_setup_tc,
- .ndo_set_rx_mode = mlxsw_sp_set_rx_mode,
+ .ndo_set_rx_mode_async = mlxsw_sp_set_rx_mode_async,
.ndo_set_mac_address = mlxsw_sp_port_set_mac_address,
.ndo_change_mtu = mlxsw_sp_port_change_mtu,
.ndo_get_stats64 = mlxsw_sp_port_get_stats64,
--
2.54.0
^ permalink raw reply related
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