* Re: [PATCH net] ipv6: validate extension header length before copying to cmsg
From: Paolo Abeni @ 2026-04-23 8:45 UTC (permalink / raw)
To: Qi Tang, davem, dsahern, edumazet, kuba, horms; +Cc: netdev, linux-kernel
In-Reply-To: <20260419150344.624673-1-tpluszz77@gmail.com>
On 4/19/26 5:03 PM, Qi Tang wrote:
> ip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR}
> cmsgs (and their IPV6_2292* legacy counterparts) by trusting the
> on-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length.
> The length was validated only at parse time (ipv6_parse_hopopts(),
> etc.). An nftables payload-write expression can rewrite hdrlen after
> parsing and before the skb reaches recvmsg; the write itself is
> in-bounds but put_cmsg() then reads up to ((hdrlen+1) << 3) = 2040
> bytes from an 8-byte header. nftables is reachable from an unprivi-
> leged user namespace, so this is an unprivileged slab-out-of-bounds
> read:
>
> BUG: KASAN: slab-out-of-bounds in put_cmsg+0x3ac/0x540
> put_cmsg+0x3ac/0x540
> udpv6_recvmsg+0xca0/0x1250
> sock_recvmsg+0xdf/0x190
> ____sys_recvmsg+0x1b1/0x620
>
> Clamp each cmsg length against skb_tail_pointer(skb) before calling
> put_cmsg(). Extension headers are kept in the linear skb area by
> pskb_may_pull() during input, so skb_tail_pointer() is the correct
> bound. The check is replicated at each call site (one HbH, four
> RFC2292 sites, and four switch cases in the DSTOPTS/RTHDR/AH walk)
> rather than hoisted out of the switch, to keep the fix minimal and
> backportable; a follow-up cleanup can factor it out. In the walk
> loop a failed check also aborts the walk, since subsequent offsets
> depend on the tampered length.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Qi Tang <tpluszz77@gmail.com>
> ---
> net/ipv6/datagram.c | 35 ++++++++++++++++++++++++++++++-----
> 1 file changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
> index ca3605acb..a7b9f5a24 100644
> --- a/net/ipv6/datagram.c
> +++ b/net/ipv6/datagram.c
> @@ -643,7 +643,10 @@ void ip6_datagram_recv_specific_ctl(struct sock *sk, struct msghdr *msg,
> /* HbH is allowed only once */
> if (np->rxopt.bits.hopopts && (opt->flags & IP6SKB_HOPBYHOP)) {
> u8 *ptr = nh + sizeof(struct ipv6hdr);
> - put_cmsg(msg, SOL_IPV6, IPV6_HOPOPTS, (ptr[1]+1)<<3, ptr);
> + u16 hbhlen = (ptr[1] + 1) << 3;
> +
> + if (ptr + hbhlen <= skb_tail_pointer(skb))
> + put_cmsg(msg, SOL_IPV6, IPV6_HOPOPTS, hbhlen, ptr);
The patch looks functionally correct to me, but the above 3 statements
are repeated multiple times. You can put them in a local helper and
avoud a lot of duplicate code.
> }
>
> if (opt->lastopt &&
> @@ -668,27 +671,37 @@ void ip6_datagram_recv_specific_ctl(struct sock *sk, struct msghdr *msg,
> case IPPROTO_DSTOPTS:
> nexthdr = ptr[0];
> len = (ptr[1] + 1) << 3;
> + if (ptr + len > skb_tail_pointer(skb))
> + goto ext_hdr_done;
The packet is corrupted, allowing processing of later rxopt requires the
IMHO not nice empty label. I think it would be better just returning
from this function.
/P
^ permalink raw reply
* Re: [PATCH RFC net-next 0/4] net: pse-pd: decouple controller lookup from MDIO probe
From: Corey Leavitt @ 2026-04-23 8:40 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Heiner Kallweit,
Russell King
Cc: Andrew Lunn, netdev, linux-kernel
In-Reply-To: <20260423-pse-notifier-decouple-v1-0-7d4856f686f6@leavitt.info>
Apologies for the noise -- this series was inadvertently sent twice. The
first send went out through an SMTP path that stripped the patatt
developer signature and re-encoded the bodies as quoted-printable.
Please disregard this thread and use the clean, signed copy as canonical:
https://lore.kernel.org/netdev/20260423-pse-notifier-decouple-v1-0-86ed750a9d62@leavitt.info/T/
Any v2 will land as a reply to that thread. Sorry for the extra inbox
traffic.
Thanks,
Corey
^ permalink raw reply
* Re: [PATCH net v2] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Paolo Abeni @ 2026-04-23 8:30 UTC (permalink / raw)
To: Daniel Golle, Chester A. Unal, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King, Christian Marangi,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek
Cc: Frank Wunderlich, John Crispin
In-Reply-To: <58aff8b5b1d691872342a6ffd3315f27854788a6.1776595131.git.daniel@makrotopia.org>
On 4/19/26 12:43 PM, Daniel Golle wrote:
> The .get_stats64 callback runs in atomic context, but on
> MDIO-connected switches every register read acquires the MDIO bus
> mutex, which can sleep:
> [ 12.645973] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:609
> [ 12.654442] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 759, name: grep
> [ 12.663377] preempt_count: 0, expected: 0
> [ 12.667410] RCU nest depth: 1, expected: 0
> [ 12.671511] INFO: lockdep is turned off.
> [ 12.675441] CPU: 0 UID: 0 PID: 759 Comm: grep Tainted: G S W 7.0.0+ #0 PREEMPT
> [ 12.675453] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
> [ 12.675456] Hardware name: Bananapi BPI-R64 (DT)
> [ 12.675459] Call trace:
> [ 12.675462] show_stack+0x14/0x1c (C)
> [ 12.675477] dump_stack_lvl+0x68/0x8c
> [ 12.675487] dump_stack+0x14/0x1c
> [ 12.675495] __might_resched+0x14c/0x220
> [ 12.675504] __might_sleep+0x44/0x80
> [ 12.675511] __mutex_lock+0x50/0xb10
> [ 12.675523] mutex_lock_nested+0x20/0x30
> [ 12.675532] mt7530_get_stats64+0x40/0x2ac
> [ 12.675542] dsa_user_get_stats64+0x2c/0x40
> [ 12.675553] dev_get_stats+0x44/0x1e0
> [ 12.675564] dev_seq_printf_stats+0x24/0xe0
> [ 12.675575] dev_seq_show+0x14/0x3c
> [ 12.675583] seq_read_iter+0x37c/0x480
> [ 12.675595] seq_read+0xd0/0xec
> [ 12.675605] proc_reg_read+0x94/0xe4
> [ 12.675615] vfs_read+0x98/0x29c
> [ 12.675625] ksys_read+0x54/0xdc
> [ 12.675633] __arm64_sys_read+0x18/0x20
> [ 12.675642] invoke_syscall.constprop.0+0x54/0xec
> [ 12.675653] do_el0_svc+0x3c/0xb4
> [ 12.675662] el0_svc+0x38/0x200
> [ 12.675670] el0t_64_sync_handler+0x98/0xdc
> [ 12.675679] el0t_64_sync+0x158/0x15c
>
> For MDIO-connected switches, poll MIB counters asynchronously using a
> delayed workqueue every second and let .get_stats64 return the cached
> values under a spinlock. A mod_delayed_work() call on each read
> triggers an immediate refresh so counters stay responsive when queried
> more frequently.
>
> MMIO-connected switches (MT7988, EN7581, AN7583) are not affected
> because their regmap does not sleep, so they continue to read MIB
> counters directly in .get_stats64.
>
> Fixes: 88c810f35ed5 ("net: dsa: mt7530: implement .get_stats64")
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> Acked-by: Chester A. Unal <chester.a.unal@arinc9.com>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> ---
> v2:
> * use spin_lock_bh()/spin_unlock_bh() to prevent potential deadlock
> * rate-limit mod_delayed_work() refresh to at most once per 100ms
> * move cancel_delayed_work_sync() after dsa_unregister_switch()
> * add mt753x_teardown() callback to cancel the stats work
> * fix commit message
>
> drivers/net/dsa/mt7530.c | 66 ++++++++++++++++++++++++++++++++++++++--
> drivers/net/dsa/mt7530.h | 8 +++++
> 2 files changed, 71 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index b9423389c2ef0..8c1186ba2279b 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -25,6 +25,9 @@
>
> #include "mt7530.h"
>
> +#define MT7530_STATS_POLL_INTERVAL (1 * HZ)
> +#define MT7530_STATS_RATE_LIMIT (HZ / 10)
> +
> static struct mt753x_pcs *pcs_to_mt753x_pcs(struct phylink_pcs *pcs)
> {
> return container_of(pcs, struct mt753x_pcs, pcs);
> @@ -906,10 +909,9 @@ static void mt7530_get_rmon_stats(struct dsa_switch *ds, int port,
> *ranges = mt7530_rmon_ranges;
> }
>
> -static void mt7530_get_stats64(struct dsa_switch *ds, int port,
> - struct rtnl_link_stats64 *storage)
> +static void mt7530_read_port_stats64(struct mt7530_priv *priv, int port,
> + struct rtnl_link_stats64 *storage)
> {
> - struct mt7530_priv *priv = ds->priv;
> uint64_t data;
>
> /* MIB counter doesn't provide a FramesTransmittedOK but instead
> @@ -951,6 +953,45 @@ static void mt7530_get_stats64(struct dsa_switch *ds, int port,
> &storage->rx_crc_errors);
> }
>
> +static void mt7530_stats_poll(struct work_struct *work)
> +{
> + struct mt7530_priv *priv = container_of(work, struct mt7530_priv,
> + stats_work.work);
> + struct rtnl_link_stats64 stats = {};
> + struct dsa_port *dp;
> + int port;
> +
> + dsa_switch_for_each_user_port(dp, priv->ds) {
> + port = dp->index;
> +
> + mt7530_read_port_stats64(priv, port, &stats);
> +
> + spin_lock_bh(&priv->stats_lock);
> + priv->ports[port].stats = stats;
> + spin_unlock_bh(&priv->stats_lock);
> + }
> +
> + priv->stats_last = jiffies;
> + schedule_delayed_work(&priv->stats_work,
> + MT7530_STATS_POLL_INTERVAL);
> +}
> +
> +static void mt7530_get_stats64(struct dsa_switch *ds, int port,
> + struct rtnl_link_stats64 *storage)
> +{
> + struct mt7530_priv *priv = ds->priv;
> +
> + if (priv->bus) {
> + spin_lock_bh(&priv->stats_lock);
> + *storage = priv->ports[port].stats;
> + spin_unlock_bh(&priv->stats_lock);
> + if (time_after(jiffies, priv->stats_last + MT7530_STATS_RATE_LIMIT))
Since both the `stats_last` access and read are lockless, it looks like
they may race leading wrong/unexpected delay. I think it would be better
move both under the spinlock (yes, the write will happen multiple times
per stats update, I don't think it will matter).
/P
^ permalink raw reply
* [PATCH v2] ipv6: fix memory leak in __ip6_make_skb() when queue is empty
From: Mingyu Wang @ 2026-04-23 8:22 UTC (permalink / raw)
To: willemdebruijn.kernel, davem, dsahern, edumazet, kuba, pabeni
Cc: sd, horms, netdev, linux-kernel, Mingyu Wang,
syzbot+e5d6936b9f4545fd88ab
During fuzzing with failslab enabled, a memory leak was observed in the
IPv6 UDP send path.
The root cause resides in __ip6_make_skb(). In extremely rare cases
(such as fault injection or specific empty payload conditions),
__ip6_append_data() may succeed but leave the socket's write queue
empty.
When __ip6_make_skb() is subsequently called, __skb_dequeue(queue)
returns NULL. The previous logic handled this by executing a 'goto out;',
which completely bypassed the call to ip6_cork_release(cork).
Since the 'cork' structure actively holds a reference to the routing
entry (dst_entry) and potentially other allocated options, skipping
the release cleanly leaks these resources.
Fix this by introducing an 'out_cork_release' label and jumping to it
when skb is NULL, ensuring the cork state is always properly cleaned up.
The now-unused 'out' label is also removed to prevent compiler warnings.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
---
net/ipv6/ip6_output.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 7e92909ab5be..82210dd5eb96 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1934,7 +1934,7 @@ struct sk_buff *__ip6_make_skb(struct sock *sk,
skb = __skb_dequeue(queue);
if (!skb)
- goto out;
+ goto out_cork_release;
tail_skb = &(skb_shinfo(skb)->frag_list);
/* move skb->data to ip header from ext header */
@@ -1998,8 +1998,8 @@ struct sk_buff *__ip6_make_skb(struct sock *sk,
ICMP6_INC_STATS(net, idev, ICMP6_MIB_OUTMSGS);
}
+out_cork_release:
ip6_cork_release(cork);
-out:
return skb;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] ipv6: fix memory leak in __ip6_make_skb() when queue is empty
From: syzbot @ 2026-04-23 8:23 UTC (permalink / raw)
To: 25181214217
Cc: 25181214217, davem, dsahern, edumazet, horms, kuba, linux-kernel,
netdev, pabeni, sd, willemdebruijn.kernel
In-Reply-To: <20260423082233.514056-1-25181214217@stu.xidian.edu.cn>
> During fuzzing with failslab enabled, a memory leak was observed in the
> IPv6 UDP send path.
>
> The root cause resides in __ip6_make_skb(). In extremely rare cases
> (such as fault injection or specific empty payload conditions),
> __ip6_append_data() may succeed but leave the socket's write queue
> empty.
>
> When __ip6_make_skb() is subsequently called, __skb_dequeue(queue)
> returns NULL. The previous logic handled this by executing a 'goto out;',
> which completely bypassed the call to ip6_cork_release(cork).
>
> Since the 'cork' structure actively holds a reference to the routing
> entry (dst_entry) and potentially other allocated options, skipping
> the release cleanly leaks these resources.
>
> Fix this by introducing an 'out_cork_release' label and jumping to it
> when skb is NULL, ensuring the cork state is always properly cleaned up.
> The now-unused 'out' label is also removed to prevent compiler warnings.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com
> Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
> ---
> net/ipv6/ip6_output.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 7e92909ab5be..82210dd5eb96 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -1934,7 +1934,7 @@ struct sk_buff *__ip6_make_skb(struct sock *sk,
>
> skb = __skb_dequeue(queue);
> if (!skb)
> - goto out;
> + goto out_cork_release;
> tail_skb = &(skb_shinfo(skb)->frag_list);
>
> /* move skb->data to ip header from ext header */
> @@ -1998,8 +1998,8 @@ struct sk_buff *__ip6_make_skb(struct sock *sk,
> ICMP6_INC_STATS(net, idev, ICMP6_MIB_OUTMSGS);
> }
>
> +out_cork_release:
> ip6_cork_release(cork);
> -out:
> return skb;
> }
>
> --
> 2.34.1
>
I see the command but can't find the corresponding bug.
The email is sent to syzbot+HASH@syzkaller.appspotmail.com address
but the HASH does not correspond to any known bug.
Please double check the address.
^ permalink raw reply
* Re: [PATCH net v2] net: iptunnel: fix stale transport header after GRE/TEB decap
From: Paolo Abeni @ 2026-04-23 8:19 UTC (permalink / raw)
To: Jiayuan Chen, Eric Dumazet
Cc: netdev, syzbot+83181a31faf9455499c5, David S. Miller, David Ahern,
Jakub Kicinski, Simon Horman, Pravin B Shelar, Tom Herbert,
linux-kernel
In-Reply-To: <eb0683d9-617f-41b6-b535-e15ffe081a17@linux.dev>
On 4/19/26 3:01 PM, Jiayuan Chen wrote:
> [...]
>>> +662,18 @@ static inline int iptunnel_pull_offloads(struct sk_buff *skb)
>>> return 0;
>>> }
>>>
>>> +static inline void iptunnel_rebuild_transport_header(struct sk_buff *skb)
>>> +{
>>> + if (!skb_is_gso(skb))
>>> + return;
>>> +
>>> + skb->transport_header = (typeof(skb->transport_header))~0U;
>>> + skb_probe_transport_header(skb);
>>> +
>>> + if (!skb_transport_header_was_set(skb))
>>> + skb_gso_reset(skb);
>> I do not think this makes sense.
>> What is a valid case for this packet being processed further?
>> The buggy packet must be dropped, instead of being mangled like this.
> Hi Eric,
>
> The reproducer builds a gre frame whose inner Ethernet header is
> all-zero. Tracing the skb through RX:
>
> 1. At GRE decap exit, skb_transport_offset(skb) < 0 is the rule, not the
> exception.
>
> It is negative for every packet leaving the tunnel, including perfectly
> well-formed inner IPv4 traffic
> because the tunnel leaves skb->transport_header at the outer L4 offset while
> pskb_pull() has already advanced skb->data past it.
Is it? the transport header is an offset on top of skb->head, pskb_pull
changes head only if the header is not in the linear part (and the
transport offset is already invalid).
> skb_transport_header_was_set() stays true, so downstream
> code that trusts that flag now trusts a stale, negative offset.
>
> 2. GRO repairs it — but only for protocols it knows.
>
> In dev_gro_receive(), skb->protocol is dispatched through the offload
> table. For ETH_P_IP,
> inet_gro_receive() calls skb_set_transport_header(skb,
> skb_gro_offset(skb)), and the offset
> becomes valid again. But for malformed skb, dev_gro_receive just bypass it.
So only malformed packets cause trouble, right?
> 3. Both kinds then reach __netif_receive_skb_core().
>
> So the skb that qdisc/tc/BPF segmenters later see has an
> invariant violation — _was_set == true but offset < 0 — that the core
> layer has no intention of catching for us.
>
> My reading of this is that the tunnel decap path is producing an skb
> that doesn't
> honor the contract __netif_receive_skb_core() expects from its
> producers, and that
> it doesn't really make sense to ask GRE to parse or validate the inner
> L4 in order
> to fix this.
>
> I'm thinking at the end of GRE decap, before handing the skb to
> gro_cells_receive(),
> call skb_reset_transport_header(skb).
My take is that you need to address the issue earlier than the current
patch, dropping the malformed packets.
/P
^ permalink raw reply
* Re: [PATCH net-deletions] net: remove ax25 and amateur radio (hamradio) subsystem
From: Toke Høiland-Jørgensen @ 2026-04-23 8:15 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, Jakub Kicinski,
corbet, skhan, federico.vaga, carlos.bilbao, avadhut.naik, alexs,
si.yanteng, dzm91, 2023002089, tsbogend, dsahern, jani.nikula,
mchehab+huawei, gregkh, jirislaby, tytso, herbert, ebiggers,
johannes.berg, geert, pablo, tglx, mashiro.chen, mingo, dqfext,
jreuter, sdf, pkshih, enelsonmoore, mkl, kees, crossd, jlayton,
wangliang74, aha310510, takamitz, kuniyu, linux-doc, linux-mips
In-Reply-To: <20260421021824.1293976-1-kuba@kernel.org>
Jakub Kicinski <kuba@kernel.org> writes:
> Remove the amateur radio (AX.25, NET/ROM, ROSE) protocol implementation
> and all associated hamradio device drivers from the kernel tree.
> This set of protocols has long been a huge bug/syzbot magnet,
> and since nobody stepped up to help us deal with the influx
> of the AI-generated bug reports we need to move it out of tree
> to protect our sanity.
>
> The code is moved to an out-of-tree repo:
> https://github.com/linux-netdev/mod-orphan
> if it's cleaned up and reworked there we can accept it back.
>
> Minimal stub headers are kept for include/net/ax25.h (AX25_P_IP,
> AX25_ADDR_LEN, ax25_address) and include/net/rose.h (ROSE_ADDR_LEN)
> so that the conditional integration code in arp.c and tun.c continues
> to compile and work when the out-of-tree modules are loaded.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
^ permalink raw reply
* Re: [PATCH net] net: airoha: fix BQL imbalance in TX path
From: Lorenzo Bianconi @ 2026-04-23 8:12 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Hariprasad Kelam
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260421-airoha-fix-bql-v1-1-f135afe4275b@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4017 bytes --]
> Fix a possible BQL imbalance in airoha_dev_xmit(), where inflight
> packets are accounted only for the AIROHA_NUM_TX_RING netdev TX
> queues. The queue index is computed as:
>
> qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma->q_tx)
> txq = netdev_get_tx_queue(dev, qid);
>
> However, airoha_qdma_tx_napi_poll() accounts completions across all
> netdev TX queues (num_tx_queues), leading to inconsistent BQL
> accounting.
>
> Also reset all netdev TX queues in the ndo_stop callback.
>
> Fixes: 1d304174106c ("net: airoha: Implement BQL support")
> Fixes: c9f947769b77 ("net: airoha: Reset BQL stopping the netdevice")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 19f67c7dd8e1..6c7390f0de5d 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -929,10 +929,9 @@ static int airoha_qdma_tx_napi_poll(struct napi_struct *napi, int budget)
> q->queued--;
>
> if (skb) {
> - u16 queue = skb_get_queue_mapping(skb);
> struct netdev_queue *txq;
>
> - txq = netdev_get_tx_queue(skb->dev, queue);
> + txq = skb_get_tx_queue(skb->dev, skb);
> netdev_tx_completed_queue(txq, 1, skb->len);
> dev_kfree_skb_any(skb);
> }
> @@ -1711,7 +1710,7 @@ static int airoha_dev_stop(struct net_device *dev)
> if (err)
> return err;
>
> - for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
> + for (i = 0; i < dev->num_tx_queues; i++)
> netdev_tx_reset_subqueue(dev, i);
>
> airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
> @@ -2002,7 +2001,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
>
> spin_lock_bh(&q->lock);
>
> - txq = netdev_get_tx_queue(dev, qid);
> + txq = skb_get_tx_queue(dev, skb);
> nr_frags = 1 + skb_shinfo(skb)->nr_frags;
>
> if (q->queued + nr_frags >= q->ndesc) {
>
> ---
> base-commit: a663bac71a2f0b3ac6c373168ca57b2a6e6381aa
> change-id: 20260421-airoha-fix-bql-7fff7cebbc9a
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
commenting on Sashiko reported issues:
https://sashiko.dev/#/patchset/20260421-airoha-fix-bql-v1-1-f135afe4275b%40kernel.org
- This isn't a bug in this patch, but does using 0xff as a sentinel value cause a permanent stall?
I do not think this is a real issue since, according to my understanding, the NIC
never writes 0xff in irq_q queue.
- This is another pre-existing issue, but does freeing the SKB here cause a DMA use-after-free
for multi-fragment packets?
This issue is not related to this patch, and I will fix it in a dedicated
patch storing the skb pointer in the last descriptor in airoha_dev_xmit()
- Since the QDMA hardware and NAPI instance are shared among multiple ports (qdma->users),
could active NAPI polling cause a BUG_ON() in dql_completed()?
This is not an issue related to this patch since here we are just resetting
all the netdev tx queues instead of just the first ARRAY_SIZE(qdma->q_tx)
ones.
- This isn't a bug in this patch, but does failing to wait for the DMA engines to become
idle before unmapping buffers cause memory corruption?
This issue is not related to this patch and it will be fixed with a dedicated
patch.
- This is also pre-existing, but can this mapping cause a kernel panic on highmem systems?
Can we have fragments in high memory? e.g on ARM architecture? Anyway, as
pointed out by Sashiko, this issue is not related to this patch.
- This isn't introduced here, but does this logic cause a permanent TX stall?
this issue is already fixed in the following patch:
https://patchwork.kernel.org/project/netdevbpf/patch/20260421-airoha-xmit-stop-condition-v1-1-e670d6a48467@kernel.org/
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net] virtio_net: sync rss_trailer.max_tx_vq on queue_pairs change via VQ_PAIRS_SET
From: Michael S. Tsirkin @ 2026-04-23 8:05 UTC (permalink / raw)
To: Paolo Abeni
Cc: Brett Creeley, jasowang, andrew+netdev, davem, edumazet, kuba,
netdev, Xuan Zhuo, Eugenio Pérez
In-Reply-To: <1222eb4d-2b6d-44c6-96a3-03c42f714b4a@redhat.com>
On Thu, Apr 23, 2026 at 09:01:26AM +0200, Paolo Abeni wrote:
> On 4/16/26 11:21 PM, Brett Creeley wrote:
> > When netif_is_rxfh_configured() is true (i.e., the user has explicitly
> > configured the RSS indirection table), virtnet_set_queues() skips the
> > RSS update path and falls through to the VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET
> > command to change the number of queue pairs. However, it does not update
> > vi->rss_trailer.max_tx_vq to reflect the new queue_pairs value.
> >
> > This causes a mismatch between vi->curr_queue_pairs and
> > vi->rss_trailer.max_tx_vq. Any subsequent RSS reconfiguration (e.g.,
> > via ethtool -X) calls virtnet_commit_rss_command(), which sends the
> > stale max_tx_vq to the device, silently reverting the queue count.
> >
> > Reproduction:
> > 1. User configured RSS
> > ethtool -X eth0 equal 8
> > 2. VQ_PAIRS_SET path; max_tx_vq stays 16
> > ethtool -L eth0 combined 12
> > 3. RSS commit uses max_tx_vq=16 instead of 12
> > ethtool -X eth0 equal 4
> >
> > Fix this by updating vi->rss_trailer.max_tx_vq after a successful
> > VQ_PAIRS_SET command when RSS is enabled, keeping it in sync with
> > curr_queue_pairs.
> >
> > Fixes: 50bfcaedd78e ("virtio_net: Update rss when set queue")
> > Assisted-by: Claude: claude-opus-4.6
> > Signed-off-by: Brett Creeley <brett.creeley@amd.com>
>
> The patch LGTM, but waiting a little longer just in case the virtio crew
> has some comments.
>
> /P
Acked-by: Michael S. Tsirkin <mst@redhat.com>
^ permalink raw reply
* [bug report] Potential refcounting issues in 'drivers/net/ethernet/mellanox/mlx4/srq.c', between 'mlx4_srq_event()' and 'mlx4_srq_free()'
From: Ginger @ 2026-04-23 8:00 UTC (permalink / raw)
To: tariqt; +Cc: netdev, linux-kernel, linux-rdma
Dear Linux kernel maintainers,
My research-based static analyzer found a potential atomicity bug
within the 'drivers/net/ethernet/mellanox/mlx4' subsystem, more
specifically, in 'drivers/net/ethernet/mellanox/mlx4/srq.c'.
Kernel version: long-term kernel v6.18.9
Potential concurrent triggering executions:
T0:
mlx4_srq_free
--> spin_lock_irq(&srq_table->lock);
--> radix_tree_delete(&srq_table->tree, srq->srqn);
--> spin_unlock_irq(&srq_table->lock);
--> if (refcount_dec_and_test(&srq->refcount))
T1:
mlx4_srq_event
--> rcu_read_lock();
--> srq = radix_tree_lookup(&srq_table->tree, srqn &
(dev->caps.num_srqs - 1));
--> rcu_read_unlock();
--> refcount_inc(&srq->refcount);
--> if (refcount_dec_and_test(&srq->refcount))
In T1, the refcounting increment on 'srq->refcount' does not check
whether this value has already reached zero in T0. In that case, if
the refcount already reaches zero, then the first 'refcount_inc()'
will increment it to one and the subsequent 'if
(refcount_dec_and_test(&srq->refcount))' will test to true, resulting
an additional call to 'complete(&srq->free)'.
This is potentially problematic for mlx4 NICs.
Thank you for your time and consideration.
Best regards,
Ginger
^ permalink raw reply
* Re: [PATCH net] net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels
From: Sebastian Andrzej Siewior @ 2026-04-23 8:00 UTC (permalink / raw)
To: Andrea Mayer
Cc: davem, dsahern, edumazet, kuba, pabeni, horms, clrkwllms, rostedt,
david.lebrun, alex.aring, stefano.salsano, netdev, linux-rt-devel,
linux-kernel, stable
In-Reply-To: <20260421094735.20997-1-andrea.mayer@uniroma2.it>
On 2026-04-21 11:47:35 [+0200], Andrea Mayer wrote:
> seg6_input_core() and rpl_input() call ip6_route_input() which sets a
> NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking
> dst_hold() unconditionally.
> On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can
> release the underlying pcpu_rt between the lookup and the caching
> through a concurrent FIB lookup on a shared nexthop.
> Simplified race sequence:
>
> ksoftirqd/X higher-prio task (same CPU X)
> ----------- --------------------------------
> seg6_input_core(,skb)/rpl_input(skb)
> dst_cache_get()
> -> miss
> ip6_route_input(skb)
> -> ip6_pol_route(,skb,flags)
> [RT6_LOOKUP_F_DST_NOREF in flags]
> -> FIB lookup resolves fib6_nh
> [nhid=N route]
> -> rt6_make_pcpu_route()
> [creates pcpu_rt, refcount=1]
> pcpu_rt->sernum = fib6_sernum
> [fib6_sernum=W]
> -> cmpxchg(fib6_nh.rt6i_pcpu,
> NULL, pcpu_rt)
> [slot was empty, store succeeds]
> -> skb_dst_set_noref(skb, dst)
> [dst is pcpu_rt, refcount still 1]
>
> rt_genid_bump_ipv6()
> -> bumps fib6_sernum
> [fib6_sernum from W to Z]
> ip6_route_output()
> -> ip6_pol_route()
> -> FIB lookup resolves fib6_nh
> [nhid=N]
> -> rt6_get_pcpu_route()
> pcpu_rt->sernum != fib6_sernum
> [W <> Z, stale]
> -> prev = xchg(rt6i_pcpu, NULL)
> -> dst_release(prev)
> [prev is pcpu_rt,
> refcount 1->0, dead]
>
> dst = skb_dst(skb)
> [dst is the dead pcpu_rt]
> dst_cache_set_ip6(dst)
> -> dst_hold() on dead dst
> -> WARN / use-after-free
So the dst passed to skb_dst_set_noref() has no reference count. The fix
is to use skb_dst_force() to increment the refcount on it. But this
requires that we are in the same RCU section. And I guess we are since
none of the warnings are visible.
Doesn't this make ip6_route_input() on RT fragile in general due to the
RT6_LOOKUP_F_DST_NOREF usage or here something special about the two
files that are patched?
Based on your explanation it all makes sense, I am just not sure if this
race is limited to those two are if there is more to it.
> For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without
> PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release
> the pcpu_rt. Shared nexthop objects provide such a path, as two routes
> pointing to the same nhid share the same fib6_nh and its rt6i_pcpu
> entry.
>
> Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after
> ip6_route_input() to force the NOREF dst into a refcounted one before
> caching.
> The output path is not affected as ip6_route_output() already returns a
> refcounted dst.
>
> Fixes: af4a2209b134 ("ipv6: sr: use dst_cache in seg6_input")
> Fixes: a7a29f9c361f ("net: ipv6: add rpl sr tunnel")
If having PREEMPT_RT_NEEDS_BH_LOCK unset is the requirement then the
right fixes: would be
Fixes: 3253cb49cbad4 ("softirq: Allow to drop the softirq-BKL lock on PREEMPT_RT")
as prior this commit the race is not possible, right?
Does this mean that rpl_input() does a local_bh_disable() while
obtaining the dst but it never runs outside of bh-disabled section?
Because if it can run in preemptible context then it would not be to
PREEMPT_RT at which point the Fixes: tags from above would make sense
again.
> Cc: stable@vger.kernel.org
> Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
Sebastian
^ permalink raw reply
* [PATCH] net: net_failover: Fix the deadlock in slave register
From: Faicker Mo @ 2026-04-23 7:59 UTC (permalink / raw)
To: sridhar.samudrala@intel.com, andrew+netdev@lunn.ch,
David S. Miller, Eric Dumazet, Paolo Abeni, sdf@fomichev.me
Cc: open list:NETWORKING DRIVERS, open list
There is netdev_lock_ops() before the NETDEV_REGISTER notifier
in register_netdevice(), so use the non-locking functions
in net_failover_slave_register().
Call Trace:
<TASK>
__schedule+0x30d/0x7a0
schedule+0x27/0x90
schedule_preempt_disabled+0x15/0x30
__mutex_lock.constprop.0+0x538/0x9e0
__mutex_lock_slowpath+0x13/0x20
mutex_lock+0x3b/0x50
dev_set_mtu+0x40/0xe0
net_failover_slave_register+0x24/0x280
failover_slave_register+0x103/0x1b0
failover_event+0x15e/0x210
? dropmon_net_event+0xac/0xe0
notifier_call_chain+0x5e/0xe0
raw_notifier_call_chain+0x16/0x30
call_netdevice_notifiers_info+0x52/0xa0
register_netdevice+0x5f4/0x7c0
register_netdev+0x1e/0x40
_mlx5e_probe+0xe2/0x370 [mlx5_core]
mlx5e_probe+0x59/0x70 [mlx5_core]
? __pfx_mlx5e_probe+0x10/0x10 [mlx5_core]
Fixes: 4c975fd70002 ("net: hold instance lock during NETDEV_REGISTER/UP")
Signed-off-by: Faicker Mo <faicker.mo@zenlayer.com>
---
drivers/net/net_failover.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/net_failover.c b/drivers/net/net_failover.c
index d0361aaf25ef..6702490eb4ed 100644
--- a/drivers/net/net_failover.c
+++ b/drivers/net/net_failover.c
@@ -502,7 +502,7 @@ static int net_failover_slave_register(struct net_device *slave_dev,
/* Align MTU of slave with failover dev */
orig_mtu = slave_dev->mtu;
- err = dev_set_mtu(slave_dev, failover_dev->mtu);
+ err = netif_set_mtu(slave_dev, failover_dev->mtu);
if (err) {
netdev_err(failover_dev, "unable to change mtu of %s to %u register failed\n",
slave_dev->name, failover_dev->mtu);
@@ -512,7 +512,7 @@ static int net_failover_slave_register(struct net_device *slave_dev,
dev_hold(slave_dev);
if (netif_running(failover_dev)) {
- err = dev_open(slave_dev, NULL);
+ err = netif_open(slave_dev, NULL);
if (err && (err != -EBUSY)) {
netdev_err(failover_dev, "Opening slave %s failed err:%d\n",
slave_dev->name, err);
@@ -565,7 +565,7 @@ static int net_failover_slave_register(struct net_device *slave_dev,
dev_close(slave_dev);
err_dev_open:
dev_put(slave_dev);
- dev_set_mtu(slave_dev, orig_mtu);
+ netif_set_mtu(slave_dev, orig_mtu);
done:
return err;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net v2] hv_sock: Return -EIO for malformed/short packets
From: Stefano Garzarella @ 2026-04-23 7:55 UTC (permalink / raw)
To: Dexuan Cui
Cc: kys, haiyangz, wei.liu, longli, davem, edumazet, kuba, pabeni,
horms, niuxuewei.nxw, linux-hyperv, virtualization, netdev,
linux-kernel, stable
In-Reply-To: <20260423064811.1371749-1-decui@microsoft.com>
On Wed, Apr 22, 2026 at 11:48:11PM -0700, Dexuan Cui wrote:
>Commit f63152958994 fixes a regression, however it fails to report an
>error for malformed/short packets -- normally we should never see such
>packets, but let's report an error for them just in case.
>
>Fixes: f63152958994 ("hv_sock: Report EOF instead of -EIO for FIN")
>Cc: stable@vger.kernel.org
>Signed-off-by: Dexuan Cui <decui@microsoft.com>
>---
>
>Commit f63152958994 is currently only in net.git's master branch.
>
>Changes since v1:
> Integrated comments from Stefano Garzarella:
>
> 1) access 'vsk' directly:
> s/hvs->vsk->peer_shutdown/vsk->peer_shutdown/
>
> 2) test the error condition first and return -EIO for that.
>
> NO other changes.
Thanks, LGTM!
Acked-by: Stefano Garzarella <sgarzare@redhat.com>
^ permalink raw reply
* Re: [PATCH net-deletions v2] net: remove unused ATM protocols and legacy ATM device drivers
From: Andy Shevchenko @ 2026-04-23 7:53 UTC (permalink / raw)
To: Philip Prindeville
Cc: David Woodhouse, Jakub Kicinski, davem, openwrt-devel, Guy Ellis,
netdev, edumazet, pabeni, andrew+netdev, horms, corbet, skhan,
linux, tsbogend, maddy, mpe, npiggin, chleroy, 3chas3, razor,
idosch, jani.nikula, mchehab+huawei, tytso, herbert, geert,
ebiggers, johannes.berg, jonathan.cameron, kees, kuniyu,
fourier.thomas, rdunlap, akpm, linux-doc, linux-mips,
linuxppc-dev, bridge
In-Reply-To: <68316F0B-2442-4492-A041-E57EFC58AC08@redfish-solutions.com>
On Wed, Apr 22, 2026 at 08:41:27PM -0600, Philip Prindeville wrote:
> > On Apr 22, 2026, at 7:05 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> > On Tue, 2026-04-21 at 21:18 -0700, Jakub Kicinski wrote:
...
> >> I'm still deleting the solos driver, chances are nobody uses it.
> >> Easy enough to revert back in since core is still around.
> >> The guiding principle is to keep USB modems and delete
> >> the rest as USB ADSL2+ CPEs were most popular historically.
> >
> > Still not entirely convinced; I worked on both USB ATM modems and on
> > Solos, and the Solos is both the most modern and the only one I still
> > actually have. And the only one we have native support for that could
> > ever do full 24Mb/s ADSL2+, I believe.
> >
> > If we drop it, OpenWrt will need to drop support for these, which I
> > think were quite popular at the time; there were a few UK resellers:
> > https://openwrt.org/toh/traverse/geos1_1
> >
> > I still don't actually care *enough* to try to find an ADSL line I
> > could plug one into for testing though... :)
>
> I have 3 boards lying around if anyone wants them.
The problem as I understand it is in one's willing to maintain and
support that driver while doing regular testing...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH net] net: airoha: Do not wake all netdev TX queues in airoha_qdma_wake_netdev_txqs()
From: Lorenzo Bianconi @ 2026-04-23 7:51 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260421-airoha-wake_netdev_txqs-optmization-v1-1-e0be95115d53@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3452 bytes --]
> Do not wake every netdev TX queue across all ports sharing the QDMA
> running netif_tx_wake_all_queues routine in airoha_qdma_wake_netdev_txqs()
> but only the ones that are mapped the specific QDMA stopped hw TX queue.
> This patch can potentially avoid waking already stopped netdev TX queues
> that are mapped to a different QDMA hw TX queue.
> Introduce airoha_qdma_get_txq utility routine.
>
> Fixes: b94769eb2f30 ("net: airoha: Fix possible TX queue stall in airoha_qdma_tx_napi_poll()")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 19 +++++++++++++++----
> drivers/net/ethernet/airoha/airoha_eth.h | 5 +++++
> 2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 19f67c7dd8e1..2ca569501045 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -847,13 +847,24 @@ static void airoha_qdma_wake_netdev_txqs(struct airoha_queue *q)
> {
> struct airoha_qdma *qdma = q->qdma;
> struct airoha_eth *eth = qdma->eth;
> - int i;
> + int i, qid = q - &qdma->q_tx[0];
>
> for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
> struct airoha_gdm_port *port = eth->ports[i];
> + int j;
> +
> + if (!port)
> + continue;
>
> - if (port && port->qdma == qdma)
> - netif_tx_wake_all_queues(port->dev);
> + if (port->qdma != qdma)
> + continue;
> +
> + for (j = 0; j < port->dev->num_tx_queues; j++) {
> + if (airoha_qdma_get_txq(qdma, j) != qid)
> + continue;
> +
> + netif_wake_subqueue(port->dev, j);
> + }
> }
> q->txq_stopped = false;
> }
> @@ -1965,7 +1976,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> u16 index;
> u8 fport;
>
> - qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma->q_tx);
> + qid = airoha_qdma_get_txq(qdma, skb_get_queue_mapping(skb));
> tag = airoha_get_dsa_tag(skb, dev);
>
> msg0 = FIELD_PREP(QDMA_ETH_TXMSG_CHAN_MASK,
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index 87b328cfefb0..c3ea7aadbd82 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -631,6 +631,11 @@ u32 airoha_rmw(void __iomem *base, u32 offset, u32 mask, u32 val);
> #define airoha_qdma_clear(qdma, offset, val) \
> airoha_rmw((qdma)->regs, (offset), (val), 0)
>
> +static inline u16 airoha_qdma_get_txq(struct airoha_qdma *qdma, u16 qid)
> +{
> + return qid % ARRAY_SIZE(qdma->q_tx);
> +}
> +
> static inline bool airoha_is_lan_gdm_port(struct airoha_gdm_port *port)
> {
> /* GDM1 port on EN7581 SoC is connected to the lan dsa switch.
>
> ---
> base-commit: a663bac71a2f0b3ac6c373168ca57b2a6e6381aa
> change-id: 20260421-airoha-wake_netdev_txqs-optmization-65171ce4ebad
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
commenting on Sashiko retported issues:
https://sashiko.dev/#/patchset/20260421-airoha-wake_netdev_txqs-optmization-v1-1-e0be95115d53%40kernel.org
- Can this cause an infinite NETDEV_TX_BUSY livelock when a QDMA hardware queue is full?
The issue is already fixed in the following patch:
https://patchwork.kernel.org/project/netdevbpf/patch/20260421-airoha-fix-bql-v1-1-f135afe4275b@kernel.org/
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net v8 4/6] net/sched: netem: validate slot configuration
From: Paolo Abeni @ 2026-04-23 7:50 UTC (permalink / raw)
To: jhs
Cc: netdev, jiri, David S. Miller, Eric Dumazet, Jakub Kicinski,
Dave Taht, open list, Stephen Hemminger, Simon Horman
In-Reply-To: <20260421131039.GA651125@horms.kernel.org>
On 4/21/26 3:10 PM, Simon Horman wrote:
> On Fri, Apr 17, 2026 at 08:19:42PM -0700, Stephen Hemminger wrote:
>> Reject slot configurations that have no defensible meaning:
>>
>> - negative min_delay or max_delay
>> - min_delay greater than max_delay
>> - negative dist_delay or dist_jitter
>> - negative max_packets or max_bytes
>>
>> Negative or out-of-order delays underflow in get_slot_next(),
>> producing garbage intervals. Negative limits trip the per-slot
>> accounting (packets_left/bytes_left <= 0) on the first packet of
>> every slot, defeating the rate-limiting half of the slot feature.
>>
>> Note that dist_jitter has been silently coerced to its absolute
>> value by get_slot() since the feature was introduced; rejecting
>> negatives here converts that silent coercion into -EINVAL. The
>> abs() can be removed in a follow-up.
>>
>> Fixes: 836af83b54e3 ("netem: support delivering packets in delayed time slots")
>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>
> Reviewed-by: Simon Horman <horms@kernel.org>
>
> I acknowledge that Sashiko has provided feedback on this patch.
>
> 1. "Does rejecting negative dist_jitter values with -EINVAL cause a
> regression in userspace ABI backward compatibility? Since the kernel
> previously accepted these values and silently coerced them using abs(),
> existing userspace tools or scripts that happen to pass negative values
> might start failing to configure the qdisc."
>
> This is intended and explicitly explained in the cover letter.
Jamal, given the uAPI implication, could you please double check that
the change is fine?
Thanks,
Paolo
^ permalink raw reply
* [PATCH net v2] net: mctp i2c: check length before marking flow active
From: William A. Kennington III @ 2026-04-23 7:46 UTC (permalink / raw)
To: Jeremy Kerr, Matt Johnston, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Wolfram Sang
Cc: William A. Kennington III, netdev, linux-kernel
In-Reply-To: <20260423001517.79219-1-william@wkennington.com>
Currently, mctp_i2c_get_tx_flow_state() is called before the packet length
sanity check. This function marks a new flow as active in the MCTP core.
If the sanity check fails, mctp_i2c_xmit() returns early without calling
mctp_i2c_lock_nest(). This results in a mismatched locking state: the
flow is active, but the I2C bus lock was never acquired for it.
When the flow is later released, mctp_i2c_release_flow() will see the
active state and queue an unlock marker. The TX thread will then
decrement midev->i2c_lock_count from 0, causing it to underflow to -1.
This underflow permanently breaks the driver's locking logic, allowing
future transmissions to occur without holding the I2C bus lock, leading
to bus collisions and potential hardware hangs.
Move the mctp_i2c_get_tx_flow_state() call to after the length sanity
check to ensure we only transition the flow state if we are actually
going to proceed with the transmission and locking.
Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver")
Signed-off-by: William A. Kennington III <william@wkennington.com>
---
drivers/net/mctp/mctp-i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mctp/mctp-i2c.c b/drivers/net/mctp/mctp-i2c.c
index 15fe4d1163c1..ee2913758e54 100644
--- a/drivers/net/mctp/mctp-i2c.c
+++ b/drivers/net/mctp/mctp-i2c.c
@@ -496,8 +496,6 @@ static void mctp_i2c_xmit(struct mctp_i2c_dev *midev, struct sk_buff *skb)
u8 *pecp;
int rc;
- fs = mctp_i2c_get_tx_flow_state(midev, skb);
-
hdr = (void *)skb_mac_header(skb);
/* Sanity check that packet contents matches skb length,
* and can't exceed MCTP_I2C_BUFSZ
@@ -509,6 +507,8 @@ static void mctp_i2c_xmit(struct mctp_i2c_dev *midev, struct sk_buff *skb)
return;
}
+ fs = mctp_i2c_get_tx_flow_state(midev, skb);
+
if (skb_tailroom(skb) >= 1) {
/* Linear case with space, we can just append the PEC */
skb_put(skb, 1);
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [RFC PATCH] net: skb: on zero-copy formatted output to skb
From: Dmitry Antipov @ 2026-04-23 7:36 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: netdev, linux-bluetooth, Dmitry Antipov
Some code, most notably the Bluetooth drivers, uses something like
the following:
char buf[80];
snprintf(buf, sizeof(buf), "Driver: %s\n", driver_name);
skb_put_data(skb, buf, strlen(buf));
This looks suboptimal at least because:
1) It yields in BUG() just in case the developer underestimates
the size of an skb being used;
2) It requires extra data copy from an external buffer;
3) It uses 'strlen()' redundantly because actual data length
is calculated by 'snprintf()' itself.
So introduce 'skb_printf()' which aims to address all of these
issues. As usual, thoughts and comments are highly appreciated.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
---
include/linux/skbuff.h | 1 +
net/core/skbuff.c | 18 ++++++++++++++++++
2 files changed, 19 insertions(+)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 2bcf78a4de7b..fb4ef55a8f86 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -4292,6 +4292,7 @@ int skb_mpls_update_lse(struct sk_buff *skb, __be32 mpls_lse);
int skb_mpls_dec_ttl(struct sk_buff *skb);
struct sk_buff *pskb_extract(struct sk_buff *skb, int off, int to_copy,
gfp_t gfp);
+int skb_printf(struct sk_buff *skb, const char *fmt, ...);
static inline int memcpy_from_msg(void *data, struct msghdr *msg, int len)
{
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7dad68e3b518..051ab4f28c75 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -6992,6 +6992,24 @@ struct sk_buff *pskb_extract(struct sk_buff *skb, int off,
}
EXPORT_SYMBOL(pskb_extract);
+int skb_printf(struct sk_buff *skb, const char *fmt, ...)
+{
+ int len, size = skb_availroom(skb);
+ va_list args;
+
+ va_start(args, fmt);
+ len = vsnprintf(skb_tail_pointer(skb), size, fmt, args);
+ va_end(args);
+
+ if (unlikely(len >= size))
+ return -ENOSPC;
+
+ skb->tail += len;
+ skb->len += len;
+ return len;
+}
+EXPORT_SYMBOL(skb_printf);
+
/**
* skb_condense - try to get rid of fragments/frag_list if possible
* @skb: buffer
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net] net: airoha: stop net_device TX queue before updating CPU index
From: Lorenzo Bianconi @ 2026-04-23 7:42 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260421-airoha-xmit-stop-condition-v1-1-e670d6a48467@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]
> Currently, airoha_eth driver updates the CPU index register prior of
> verifying whether the number of free descriptors has fallen below the
> threshold.
> Move net_device TX queue length check before updating the TX CPU index
> in order to update TX CPU index even if there are more packets to be
> transmitted but the net_device TX queue is going to be stopped
> accounting the inflight packets.
>
> Fixes: 1d304174106c ("net: airoha: Implement BQL support")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 19f67c7dd8e1..5d327237e274 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2058,17 +2058,16 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
>
> skb_tx_timestamp(skb);
> netdev_tx_sent_queue(txq, skb->len);
> + if (q->ndesc - q->queued < q->free_thr) {
> + netif_tx_stop_queue(txq);
> + q->txq_stopped = true;
> + }
>
> if (netif_xmit_stopped(txq) || !netdev_xmit_more())
> airoha_qdma_rmw(qdma, REG_TX_CPU_IDX(qid),
> TX_RING_CPU_IDX_MASK,
> FIELD_PREP(TX_RING_CPU_IDX_MASK, index));
>
> - if (q->ndesc - q->queued < q->free_thr) {
> - netif_tx_stop_queue(txq);
> - q->txq_stopped = true;
> - }
> -
> spin_unlock_bh(&q->lock);
>
> return NETDEV_TX_OK;
>
> ---
> base-commit: a663bac71a2f0b3ac6c373168ca57b2a6e6381aa
> change-id: 20260421-airoha-xmit-stop-condition-344dc0292a19
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
commenting on Sashiko retported issues:
https://sashiko.dev/#/patchset/20260421-airoha-xmit-stop-condition-v1-1-e670d6a48467%40kernel.org
- Could this cause a deadlock if exactly q->free_thr descriptors are free?
This does not seem a problem to me since, even if the netdev tx queue is
stopped as described in the report, the airoha_qdma_tx_napi_poll() will free
space in the queue and subsequent packets will update REG_TX_CPU_IDX register.
- Is it possible for this loop to read past the end of the frags array?
As pointed out by Sashiko, this issue is not introduced by this patch and I
will fix with a dedicated patch.
- Might this lead to memory corruption if the tcp header is not in the linear area?
This issue is not introduced by this patch and I will fix with a dedicated patch.
- If an error occurs during transmission, the driver jumps to the error label
frees the skb, and returns NETDEV_TX_OK without ringing the qdma cpu index doorbell?
Similar to the first issue, this does not seem a problem to me since subsequent
packets will update REG_TX_CPU_IDX register.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH RFC net-next 2/4] net: pse-pd: add notifier chain for controller lifecycle events
From: Corey Leavitt via B4 Relay @ 2026-04-23 7:42 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Heiner Kallweit,
Russell King
Cc: Andrew Lunn, netdev, linux-kernel, Corey Leavitt
In-Reply-To: <20260423-pse-notifier-decouple-v1-0-86ed750a9d62@leavitt.info>
From: Corey Leavitt <corey@leavitt.info>
Introduce a blocking notifier chain that allows other subsystems to be
informed when a PSE controller is registered or unregistered, and
provide pse_register_notifier() / pse_unregister_notifier() as the
subscriber interface.
Subsequent patches will use this to let the phy subsystem own the
phydev->psec lifecycle directly, decoupling PSE lookup from
fwnode_mdiobus_register_phy() and removing the probe-time
-EPROBE_DEFER coupling that currently exists between mdio, phy and
pse-pd when the PSE controller driver is modular.
A blocking chain (rather than atomic) is used because callbacks will
take rtnl_lock and call back into pse_core via of_pse_control_get().
The enum pse_controller_event is placed outside the
IS_ENABLED(CONFIG_PSE_CONTROLLER) guard so that subscribers compiled
into a kernel without PSE support can still reference the event
values in dead-code paths without breaking the build.
This patch is pure infrastructure: nothing fires events yet, and
nothing subscribes. No observable behavior change.
Signed-off-by: Corey Leavitt <corey@leavitt.info>
---
drivers/net/pse-pd/pse_core.c | 34 ++++++++++++++++++++++++++++++++++
include/linux/pse-pd/pse.h | 32 ++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+)
diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 893ec2185947..80c5c6c1758c 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -8,6 +8,7 @@
#include <linux/device.h>
#include <linux/ethtool.h>
#include <linux/ethtool_netlink.h>
+#include <linux/notifier.h>
#include <linux/of.h>
#include <linux/phy.h>
#include <linux/pse-pd/pse.h>
@@ -23,6 +24,39 @@ static LIST_HEAD(pse_controller_list);
static DEFINE_XARRAY_ALLOC(pse_pw_d_map);
static DEFINE_MUTEX(pse_pw_d_mutex);
+static BLOCKING_NOTIFIER_HEAD(pse_controller_notifier);
+
+/**
+ * pse_register_notifier - register a callback for PSE controller events
+ * @nb: notifier block to register
+ *
+ * See enum pse_controller_event for events fired and their subscriber
+ * contract. Callbacks run in process context; they may sleep, take
+ * rtnl, and call of_pse_control_get(). The chain fires synchronously,
+ * so a PSE controller driver's probe/unbind path must not hold any
+ * such lock when calling pse_controller_register() or
+ * pse_controller_unregister().
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+int pse_register_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(&pse_controller_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(pse_register_notifier);
+
+/**
+ * pse_unregister_notifier - unregister a previously registered callback
+ * @nb: notifier block previously passed to pse_register_notifier()
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+int pse_unregister_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(&pse_controller_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(pse_unregister_notifier);
+
/**
* struct pse_control - a PSE control
* @pcdev: a pointer to the PSE controller device
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index 4e5696cfade7..78fe3a2b1ea8 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -21,6 +21,7 @@ struct net_device;
struct phy_device;
struct pse_controller_dev;
struct netlink_ext_ack;
+struct notifier_block;
/* C33 PSE extended state and substate. */
struct ethtool_c33_pse_ext_state_info {
@@ -337,6 +338,24 @@ enum pse_budget_eval_strategies {
PSE_BUDGET_EVAL_STRAT_DYNAMIC = 1 << 2,
};
+/**
+ * enum pse_controller_event - PSE controller lifecycle events
+ *
+ * Event data in callbacks is always a pointer to the struct
+ * pse_controller_dev firing the event.
+ *
+ * @PSE_REGISTERED: controller added to pse_controller_list and
+ * resolvable by of_pse_control_get().
+ * @PSE_UNREGISTERED: controller about to be removed from
+ * pse_controller_list. Subscribers holding pse_control references
+ * targeting it must drop them before returning and must not
+ * acquire new references for it.
+ */
+enum pse_controller_event {
+ PSE_REGISTERED,
+ PSE_UNREGISTERED,
+};
+
#if IS_ENABLED(CONFIG_PSE_CONTROLLER)
int pse_controller_register(struct pse_controller_dev *pcdev);
void pse_controller_unregister(struct pse_controller_dev *pcdev);
@@ -366,6 +385,9 @@ int pse_ethtool_set_prio(struct pse_control *psec,
bool pse_has_podl(struct pse_control *psec);
bool pse_has_c33(struct pse_control *psec);
+int pse_register_notifier(struct notifier_block *nb);
+int pse_unregister_notifier(struct notifier_block *nb);
+
#else
static inline struct pse_control *of_pse_control_get(struct device_node *node,
@@ -416,6 +438,16 @@ static inline bool pse_has_c33(struct pse_control *psec)
return false;
}
+static inline int pse_register_notifier(struct notifier_block *nb)
+{
+ return 0;
+}
+
+static inline int pse_unregister_notifier(struct notifier_block *nb)
+{
+ return 0;
+}
+
#endif
#endif
--
2.53.0
^ permalink raw reply related
* [PATCH RFC net-next 1/4] net: pse-pd: scope pse_control regulator handle to kref lifetime
From: Corey Leavitt via B4 Relay @ 2026-04-23 7:42 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Heiner Kallweit,
Russell King
Cc: Andrew Lunn, netdev, linux-kernel, Corey Leavitt
In-Reply-To: <20260423-pse-notifier-decouple-v1-0-86ed750a9d62@leavitt.info>
From: Corey Leavitt <corey@leavitt.info>
__pse_control_release() drops psec->ps via devm_regulator_put(), which
only succeeds if the devres entry added by the matching
devm_regulator_get_exclusive() is still present on pcdev->dev at the
time the pse_control's kref hits zero.
In practice that assumption does not hold when the controller is
unbound while any pse_control still has consumers: pcdev->dev's
devres list is released LIFO, so every per-attach regulator-GET
devres runs (and regulator_put()s the underlying regulator) before
pse_controller_unregister() itself is invoked. Any later
pse_control_put() from that unbind path then reads psec->ps as a
dangling pointer inside devm_regulator_put() and WARNs at
drivers/regulator/devres.c:232 (devres_release() fails to find the
already-released match).
The pse_control's consumer handle is logically scoped to the
pse_control's refcount, not to pcdev->dev's devres lifetime. Switch
to the plain regulator_get_exclusive() / regulator_put() pair so
__pse_control_release() does the right put regardless of whether
the controller's devres has already been unwound.
No change to the regulator-framework-visible refcount or lifetime of
the underlying regulator: a single get paired with a single put. The
existing devm_regulator_register() for the per-PI rails is unchanged
(those ARE correctly scoped to the controller's lifetime).
Fixes: d83e13761d5b ("net: pse-pd: Use regulator framework within PSE framework")
Signed-off-by: Corey Leavitt <corey@leavitt.info>
---
drivers/net/pse-pd/pse_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index f6b94ac7a68a..893ec2185947 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -1362,7 +1362,7 @@ static void __pse_control_release(struct kref *kref)
if (psec->pcdev->pi[psec->id].admin_state_enabled)
regulator_disable(psec->ps);
- devm_regulator_put(psec->ps);
+ regulator_put(psec->ps);
module_put(psec->pcdev->owner);
@@ -1431,8 +1431,8 @@ pse_control_get_internal(struct pse_controller_dev *pcdev, unsigned int index,
goto free_psec;
pcdev->pi[index].admin_state_enabled = ret;
- psec->ps = devm_regulator_get_exclusive(pcdev->dev,
- rdev_get_name(pcdev->pi[index].rdev));
+ psec->ps = regulator_get_exclusive(pcdev->dev,
+ rdev_get_name(pcdev->pi[index].rdev));
if (IS_ERR(psec->ps)) {
ret = PTR_ERR(psec->ps);
goto put_module;
--
2.53.0
^ permalink raw reply related
* [PATCH RFC net-next 4/4] net: phy: own phydev->psec via PSE notifier and remove fwnode_mdio hook
From: Corey Leavitt via B4 Relay @ 2026-04-23 7:42 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Heiner Kallweit,
Russell King
Cc: Andrew Lunn, netdev, linux-kernel, Corey Leavitt
In-Reply-To: <20260423-pse-notifier-decouple-v1-0-86ed750a9d62@leavitt.info>
From: Corey Leavitt <corey@leavitt.info>
Transfer ownership of phydev->psec from fwnode_mdio to the phy
subsystem itself. The phy subsystem now subscribes to the pse-pd
notifier chain and manages psec attach/detach in response to PSE
controller lifecycle events, while fwnode_mdio loses its PSE
awareness entirely.
Split phy_device_register() into a public entry point that takes
rtnl_lock() and a phy_device_register_locked() variant that assumes
rtnl is already held. Callers that already hold rtnl (the SFP
module state machine via __sfp_sm_event) use the _locked form to
avoid deadlock; all other callers use the unchanged public API.
This pair mirrors the register_netdevice() / register_netdev()
split convention already established in the core networking stack.
rtnl must span the full registration sequence through device_add(),
not just phy_try_attach_pse(): a PSE_REGISTERED event firing between
a narrow attach lock and device_add() would walk mdio_bus_type, find
the phy not yet on the bus, and leave it permanently unattached.
With rtnl held across the full registration sequence:
- At phy_device_register_locked(), phy_try_attach_pse() attempts
an of_pse_control_get() for phys whose DT pses phandle resolves
now. If the controller is already registered, psec is attached
before device_add() makes the phy visible on mdio_bus_type.
If the controller is not yet registered, the swallow-error path
leaves psec NULL and relies on the subsequent notifier event.
- On PSE_REGISTERED: an rtnl-guarded bus walk retries the attach
for every registered phy whose psec is still NULL. This is the
"phy was enumerated before the PSE controller loaded" case,
which is the root cause of the boot-time probe-retry storm on
systems with a modular PSE controller driver. Because the
pse_controller_notifier is fired synchronously, a concurrent
pse_controller_register() either (a) completes list_add and
releases pse_list_mutex before this function takes rtnl, in
which case phy_try_attach_pse() finds the controller in the
list and attaches; or (b) fires its notifier during this
function, in which case the callback blocks on rtnl until this
function returns, then walks the bus and finds the phy fully
registered (attaching if psec is still NULL).
- On PSE_UNREGISTERED: an rtnl-guarded bus walk releases every
phydev->psec that targets the departing controller before
pse_release_pis() frees pcdev->pi. Without this, a phy still
holding a pse_control reference would cause a use-after-free
in __pse_control_release's pcdev->pi[psec->id] access, and the
PSE driver module could not finish unloading while any phy
still held a reference via module_put().
Introduce phy_try_attach_pse() as the rtnl-guarded helper used by
both the register path and the notifier walk. Holding rtnl across
of_pse_control_get() is safe because pse_list_mutex is never held
in the opposite order.
Expose pse_control_matches_pcdev() as a predicate so subscribers
can identify which of their held pse_control references target a
given controller, without leaking the struct pse_controller_dev *
out of pse_control opacity.
Move the final pse_control_put() of phydev->psec from
phy_device_remove() to phy_device_release(). The kobject release
callback runs only after every reference on the device has been
dropped, including the bus iterator references taken by
bus_for_each_dev() in the notifier walk, which means by the time
release fires no concurrent reader or writer of phydev->psec can
exist. The mdio_bus_type klist is set up in bus_register() with
klist_devices_get() / klist_devices_put() (drivers/base/bus.c),
which bracket each iteration step with get_device() / put_device()
on the underlying struct device; that reference defers the release
callback from firing until the walk has advanced past this phy.
Keeping phy_device_remove() unchanged avoids introducing a new
locking contract on its many callers (sfp, fixed_phy, xgbe, hns,
netsec, bcm_sf2, mdiobus_unregister).
Finally, delete fwnode_find_pse_control() and its call site in
fwnode_mdiobus_register_phy(), and drop the PSE header from
fwnode_mdio.c. This removes the probe-time -EPROBE_DEFER coupling
between mdio and pse-pd that caused the boot-hang regression on
systems with a modular PSE controller driver and a DT phy with a
pses phandle: the MDIO/DSA probe no longer sees any PSE-originated
-EPROBE_DEFER, so the probe-retry storm is gone. fwnode_mdio is
now PSE-agnostic.
Fixes: fa2f0454174c ("net: pse-pd: Introduce attached_phydev to pse control")
Signed-off-by: Corey Leavitt <corey@leavitt.info>
---
drivers/net/mdio/fwnode_mdio.c | 34 ----------
drivers/net/phy/phy_device.c | 144 ++++++++++++++++++++++++++++++++++++++---
drivers/net/phy/sfp.c | 2 +-
drivers/net/pse-pd/pse_core.c | 14 ++++
include/linux/phy.h | 2 +
include/linux/pse-pd/pse.h | 9 +++
6 files changed, 161 insertions(+), 44 deletions(-)
diff --git a/drivers/net/mdio/fwnode_mdio.c b/drivers/net/mdio/fwnode_mdio.c
index ba7091518265..7bd979b59f49 100644
--- a/drivers/net/mdio/fwnode_mdio.c
+++ b/drivers/net/mdio/fwnode_mdio.c
@@ -11,33 +11,11 @@
#include <linux/fwnode_mdio.h>
#include <linux/of.h>
#include <linux/phy.h>
-#include <linux/pse-pd/pse.h>
MODULE_AUTHOR("Calvin Johnson <calvin.johnson@oss.nxp.com>");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("FWNODE MDIO bus (Ethernet PHY) accessors");
-static struct pse_control *
-fwnode_find_pse_control(struct fwnode_handle *fwnode,
- struct phy_device *phydev)
-{
- struct pse_control *psec;
- struct device_node *np;
-
- if (!IS_ENABLED(CONFIG_PSE_CONTROLLER))
- return NULL;
-
- np = to_of_node(fwnode);
- if (!np)
- return NULL;
-
- psec = of_pse_control_get(np, phydev);
- if (PTR_ERR(psec) == -ENOENT)
- return NULL;
-
- return psec;
-}
-
static struct mii_timestamper *
fwnode_find_mii_timestamper(struct fwnode_handle *fwnode)
{
@@ -118,7 +96,6 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
struct fwnode_handle *child, u32 addr)
{
struct mii_timestamper *mii_ts = NULL;
- struct pse_control *psec = NULL;
struct phy_device *phy;
bool is_c45;
u32 phy_id;
@@ -159,14 +136,6 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
goto clean_phy;
}
- psec = fwnode_find_pse_control(child, phy);
- if (IS_ERR(psec)) {
- rc = PTR_ERR(psec);
- goto unregister_phy;
- }
-
- phy->psec = psec;
-
/* phy->mii_ts may already be defined by the PHY driver. A
* mii_timestamper probed via the device tree will still have
* precedence.
@@ -176,9 +145,6 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
return 0;
-unregister_phy:
- if (is_acpi_node(child) || is_of_node(child))
- phy_device_remove(phy);
clean_phy:
phy_device_free(phy);
clean_mii_ts:
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index c2cdf1ae3542..7948800e6e49 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -223,8 +223,19 @@ static void phy_mdio_device_free(struct mdio_device *mdiodev)
static void phy_device_release(struct device *dev)
{
+ struct phy_device *phydev = to_phy_device(dev);
+
+ /* bus_for_each_dev() holds get_device() across each iteration
+ * step, deferring this release callback until any in-flight PSE
+ * notifier walk has advanced past this phy. pse_control_put()
+ * takes pse_list_mutex, so this path must run in sleepable
+ * context.
+ */
+ might_sleep();
+ pse_control_put(phydev->psec);
+
fwnode_handle_put(dev->fwnode);
- kfree(to_phy_device(dev));
+ kfree(phydev);
}
static void phy_mdio_device_remove(struct mdio_device *mdiodev)
@@ -1102,14 +1113,102 @@ struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45)
}
EXPORT_SYMBOL(get_phy_device);
-/**
- * phy_device_register - Register the phy device on the MDIO bus
- * @phydev: phy_device structure to be added to the MDIO bus
+/* Best-effort attach of phydev->psec from a DT `pses = <&...>` phandle.
+ * Caller must hold rtnl. Errors are swallowed; the notifier retries
+ * at PSE_REGISTERED time.
*/
-int phy_device_register(struct phy_device *phydev)
+static void phy_try_attach_pse(struct phy_device *phydev)
+{
+ struct pse_control *psec;
+ struct device_node *np;
+
+ ASSERT_RTNL();
+
+ np = phydev->mdio.dev.of_node;
+ if (!np)
+ return;
+
+ if (phydev->psec)
+ return;
+
+ psec = of_pse_control_get(np, phydev);
+ if (IS_ERR(psec))
+ return;
+
+ phydev->psec = psec;
+}
+
+static int phy_pse_attach_one(struct device *dev, void *data __maybe_unused)
+{
+ ASSERT_RTNL();
+
+ if (dev->type != &mdio_bus_phy_type)
+ return 0;
+
+ phy_try_attach_pse(to_phy_device(dev));
+ return 0;
+}
+
+static int phy_pse_detach_one(struct device *dev, void *data)
+{
+ struct pse_controller_dev *pcdev = data;
+ struct phy_device *phydev;
+ struct pse_control *psec;
+
+ ASSERT_RTNL();
+
+ if (dev->type != &mdio_bus_phy_type)
+ return 0;
+
+ phydev = to_phy_device(dev);
+ psec = phydev->psec;
+ if (!psec || !pse_control_matches_pcdev(psec, pcdev))
+ return 0;
+
+ phydev->psec = NULL;
+ pse_control_put(psec);
+ return 0;
+}
+
+static int phy_pse_notifier_event(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ switch (event) {
+ case PSE_REGISTERED:
+ rtnl_lock();
+ bus_for_each_dev(&mdio_bus_type, NULL, NULL,
+ phy_pse_attach_one);
+ rtnl_unlock();
+ return NOTIFY_OK;
+ case PSE_UNREGISTERED:
+ rtnl_lock();
+ bus_for_each_dev(&mdio_bus_type, NULL, data,
+ phy_pse_detach_one);
+ rtnl_unlock();
+ return NOTIFY_OK;
+ default:
+ return NOTIFY_DONE;
+ }
+}
+
+static struct notifier_block phy_pse_notifier __read_mostly = {
+ .notifier_call = phy_pse_notifier_event,
+};
+
+/**
+ * phy_device_register_locked - Register the phy device on the MDIO bus
+ * @phydev: phy_device structure to be added to the MDIO bus
+ *
+ * Same as phy_device_register() but caller must already hold rtnl_lock().
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int phy_device_register_locked(struct phy_device *phydev)
{
int err;
+ ASSERT_RTNL();
+
err = mdiobus_register_device(&phydev->mdio);
if (err)
return err;
@@ -1124,6 +1223,8 @@ int phy_device_register(struct phy_device *phydev)
goto out;
}
+ phy_try_attach_pse(phydev);
+
err = device_add(&phydev->mdio.dev);
if (err) {
phydev_err(phydev, "failed to add\n");
@@ -1133,12 +1234,32 @@ int phy_device_register(struct phy_device *phydev)
return 0;
out:
- /* Assert the reset signal */
+ /* If phy_try_attach_pse() set phydev->psec before device_add()
+ * failed, the caller's phy_device_free() -> phy_device_release()
+ * chain will drop it.
+ */
phy_device_reset(phydev, 1);
-
mdiobus_unregister_device(&phydev->mdio);
return err;
}
+EXPORT_SYMBOL(phy_device_register_locked);
+
+/**
+ * phy_device_register - Register the phy device on the MDIO bus
+ * @phydev: phy_device structure to be added to the MDIO bus
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int phy_device_register(struct phy_device *phydev)
+{
+ int err;
+
+ rtnl_lock();
+ err = phy_device_register_locked(phydev);
+ rtnl_unlock();
+
+ return err;
+}
EXPORT_SYMBOL(phy_device_register);
/**
@@ -1152,8 +1273,6 @@ EXPORT_SYMBOL(phy_device_register);
void phy_device_remove(struct phy_device *phydev)
{
unregister_mii_timestamper(phydev->mii_ts);
- pse_control_put(phydev->psec);
-
device_del(&phydev->mdio.dev);
/* Assert the reset signal */
@@ -3962,8 +4081,14 @@ static int __init phy_init(void)
if (rc)
goto err_c45;
+ rc = pse_register_notifier(&phy_pse_notifier);
+ if (rc)
+ goto err_genphy;
+
return 0;
+err_genphy:
+ phy_driver_unregister(&genphy_driver);
err_c45:
phy_driver_unregister(&genphy_c45_driver);
err_ethtool_phy_ops:
@@ -3980,6 +4105,7 @@ static int __init phy_init(void)
static void __exit phy_exit(void)
{
+ pse_unregister_notifier(&phy_pse_notifier);
phy_driver_unregister(&genphy_c45_driver);
phy_driver_unregister(&genphy_driver);
rtnl_lock();
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index bd970f753beb..d19fe0f30c5d 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -1932,7 +1932,7 @@ static int sfp_sm_probe_phy(struct sfp *sfp, int addr, bool is_c45)
/* Mark this PHY as being on a SFP module */
phy->is_on_sfp_module = true;
- err = phy_device_register(phy);
+ err = phy_device_register_locked(phy);
if (err) {
phy_device_free(phy);
dev_err(sfp->dev, "phy_device_register failed: %pe\n",
diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 82125502a8e3..a0667324a029 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -2016,3 +2016,17 @@ bool pse_has_c33(struct pse_control *psec)
return psec->pcdev->types & ETHTOOL_PSE_C33;
}
EXPORT_SYMBOL_GPL(pse_has_c33);
+
+/**
+ * pse_control_matches_pcdev - Test whether a pse_control targets a controller
+ * @psec: pse_control obtained from of_pse_control_get()
+ * @pcdev: PSE controller to compare against
+ *
+ * Return: %true if @psec was obtained from @pcdev, %false otherwise.
+ */
+bool pse_control_matches_pcdev(struct pse_control *psec,
+ struct pse_controller_dev *pcdev)
+{
+ return psec->pcdev == pcdev;
+}
+EXPORT_SYMBOL_GPL(pse_control_matches_pcdev);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 199a7aaa341b..865b9baddb85 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -2158,6 +2158,8 @@ struct phy_device *fwnode_phy_find_device(struct fwnode_handle *phy_fwnode);
struct fwnode_handle *fwnode_get_phy_node(const struct fwnode_handle *fwnode);
struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
int phy_device_register(struct phy_device *phy);
+/* Caller must hold rtnl_lock(); see phy_device_register() for the public form. */
+int phy_device_register_locked(struct phy_device *phy);
void phy_device_free(struct phy_device *phydev);
void phy_device_remove(struct phy_device *phydev);
int phy_get_c45_ids(struct phy_device *phydev);
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index 78fe3a2b1ea8..d4310ca71a3e 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -385,6 +385,9 @@ int pse_ethtool_set_prio(struct pse_control *psec,
bool pse_has_podl(struct pse_control *psec);
bool pse_has_c33(struct pse_control *psec);
+bool pse_control_matches_pcdev(struct pse_control *psec,
+ struct pse_controller_dev *pcdev);
+
int pse_register_notifier(struct notifier_block *nb);
int pse_unregister_notifier(struct notifier_block *nb);
@@ -438,6 +441,12 @@ static inline bool pse_has_c33(struct pse_control *psec)
return false;
}
+static inline bool pse_control_matches_pcdev(struct pse_control *psec,
+ struct pse_controller_dev *pcdev)
+{
+ return false;
+}
+
static inline int pse_register_notifier(struct notifier_block *nb)
{
return 0;
--
2.53.0
^ permalink raw reply related
* [PATCH RFC net-next 3/4] net: pse-pd: fire lifecycle events on controller register/unregister
From: Corey Leavitt via B4 Relay @ 2026-04-23 7:42 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Heiner Kallweit,
Russell King
Cc: Andrew Lunn, netdev, linux-kernel, Corey Leavitt
In-Reply-To: <20260423-pse-notifier-decouple-v1-0-86ed750a9d62@leavitt.info>
From: Corey Leavitt <corey@leavitt.info>
Hook the newly-introduced pse_controller_notifier chain so that
pse_controller_register() fires PSE_REGISTERED after the controller
has been added to pse_controller_list (i.e. is now resolvable by
of_pse_control_get()), and pse_controller_unregister() fires
PSE_UNREGISTERED before the controller is removed from the list
(while it is still valid to dereference from a subscriber's
pse_control pointer targeting it).
With no subscribers yet, this is observably a no-op. A later change
wires the phy subsystem in as the first subscriber.
Signed-off-by: Corey Leavitt <corey@leavitt.info>
---
drivers/net/pse-pd/pse_core.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 80c5c6c1758c..82125502a8e3 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -1138,6 +1138,9 @@ int pse_controller_register(struct pse_controller_dev *pcdev)
list_add(&pcdev->list, &pse_controller_list);
mutex_unlock(&pse_list_mutex);
+ blocking_notifier_call_chain(&pse_controller_notifier,
+ PSE_REGISTERED, pcdev);
+
return 0;
}
EXPORT_SYMBOL_GPL(pse_controller_register);
@@ -1148,6 +1151,9 @@ EXPORT_SYMBOL_GPL(pse_controller_register);
*/
void pse_controller_unregister(struct pse_controller_dev *pcdev)
{
+ blocking_notifier_call_chain(&pse_controller_notifier,
+ PSE_UNREGISTERED, pcdev);
+
pse_flush_pw_ds(pcdev);
pse_release_pis(pcdev);
if (pcdev->irq)
--
2.53.0
^ permalink raw reply related
* [PATCH RFC net-next 0/4] net: pse-pd: decouple controller lookup from MDIO probe
From: Corey Leavitt via B4 Relay @ 2026-04-23 7:42 UTC (permalink / raw)
To: Oleksij Rempel, Kory Maincent, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Heiner Kallweit,
Russell King
Cc: Andrew Lunn, netdev, linux-kernel, Corey Leavitt
On systems where a PSE controller driver loads as a module and a
device-tree PHY node carries a `pses = <&pse_pi>` reference,
fwnode_mdiobus_register_phy() tries to resolve the PSE handle before
the controller driver has probed. of_pse_control_get() returns
-EPROBE_DEFER, the enclosing MDIO/DSA probe fails, and driver-core
re-queues the work. The retry loop spins until the PSE driver module
loads and its controller registers.
Commit fa2f0454174c ("net: pse-pd: Introduce attached_phydev to pse
control") made each retry expensive. It reordered
fwnode_mdiobus_register_phy() so the PHY is registered before the
PSE lookup. Every deferral now performs a full
phy_device_register() / phy_device_remove() cycle. On a board with a
sufficiently tight watchdog the retry loop can starve the watchdog
kthread. On the reporting hardware (MT7621 + gpio-wdt, 1-second
margin) the retry loop converts a slow probe phase into a reset
before userspace loads.
The affected population today looks small. OpenWrt, where PSE
actually ships, is still on 6.12 (pre-regression), and most
environments with CONFIG_PSE_*=m do not have boards whose DT
references a PSE controller from a PHY. Still, the mechanism is
general. Any modular PSE driver combined with the documented
`pses = <&...>` binding reproduces the retry loop. Whether it
reaches brick-grade or merely slow/flaky boot depends on local
watchdog timing. More exposure is expected as distribution and
embedded kernels move to 6.13 and later.
The narrow fix would be to partially revert the ordering in
fa2f0454174c so each defer is cheap again. That keeps the same
architecture (fwnode_mdio holding PSE knowledge, -EPROBE_DEFER
flowing across the subsystem boundary), and any future reorder
reintroduces the same class of bug. This series takes the larger
fix: decouple PSE controller lookup from MDIO registration entirely.
pse_core now publishes a BLOCKING_NOTIFIER chain with REGISTERED
and UNREGISTERED events. phy_device subscribes, owns phydev->psec
lifetime, and attaches PSE handles in response to controller
lifecycle rather than during probe. fwnode_mdio loses its PSE
awareness, and -EPROBE_DEFER no longer flows out of fwnode_mdio.
Patch breakdown:
1. Scope the pse_control regulator handle to kref lifetime
(Fixes: d83e13761d5b). A latent bug that patch 4 makes
reachable.
2. Add the notifier chain (enum, head, register/unregister
helpers). Pure infrastructure. No subscribers yet, no
observable change.
3. Fire REGISTERED and UNREGISTERED events from the controller
register/unregister paths. Still no subscribers, still no
observable change.
4. Subscribe from the PHY layer, take ownership of phydev->psec
via the notifier, and remove fwnode_find_pse_control() from
fwnode_mdio.
Patch 1 is bundled here per stable-kernel-rules section 4
reachability guidance. On mainline today, with no notifier
subscriber, no caller drives the dangling regulator-handle sequence.
Patches 2 and 3 are deliberately split to separate "add
infrastructure" from "wire it up". Happy to fold them if maintainers
prefer the combined form.
Validated on a Cudy C200P (MT7621 + IP804AR) running an OpenWrt
build of 6.18.21 with the series applied. A lockdep build
(CONFIG_PROVE_LOCKING + CONFIG_DEBUG_ATOMIC_SLEEP) shows no splats
from the series' code paths during boot, PHY attach, PHY detach, or
a full controller unbind/rebind cycle. ethtool --set-pse drives all
four PoE-capable LAN ports, and a Ruckus H510 class-4 PD plugged
into lan3 negotiates and receives 48 V.
The C200P has no SFP cage, so the SFP path change in sfp.c
(phy_device_register -> phy_device_register_locked) isn't exercised
on the bench. Verified by call-graph audit: every path reaching
sfp_sm_probe_phy() holds rtnl at entry, via sfp_timeout,
sfp_check_state, sfp_probe, sfp_remove, or
sfp_bus_{add,del}_upstream.
Not addressed by this series: ethtool --show-pse returns "No data
available" on DSA netdevs in 6.18, because dev->phydev is NULL for
DSA-frontend netdevs and ethnl_req_get_phydev() therefore returns
NULL. That's a DSA / ethtool integration quirk that predates this
work.
Sending as RFC because this is my first net-next series. I'd
appreciate maintainer guidance on whether patch 1 should go to net
rather than net-next, and whether the patch 2/3 split is preferred
to the combined form.
Signed-off-by: Corey Leavitt <corey@leavitt.info>
---
Corey Leavitt (4):
net: pse-pd: scope pse_control regulator handle to kref lifetime
net: pse-pd: add notifier chain for controller lifecycle events
net: pse-pd: fire lifecycle events on controller register/unregister
net: phy: own phydev->psec via PSE notifier and remove fwnode_mdio hook
drivers/net/mdio/fwnode_mdio.c | 34 ----------
drivers/net/phy/phy_device.c | 144 ++++++++++++++++++++++++++++++++++++++---
drivers/net/phy/sfp.c | 2 +-
drivers/net/pse-pd/pse_core.c | 60 ++++++++++++++++-
include/linux/phy.h | 2 +
include/linux/pse-pd/pse.h | 41 ++++++++++++
6 files changed, 236 insertions(+), 47 deletions(-)
---
base-commit: 1f5ffc672165ff851063a5fd044b727ab2517ae3
change-id: 20260422-pse-notifier-decouple-efa80d77f4be
Best regards,
--
Corey Leavitt <corey@leavitt.info>
^ permalink raw reply
* Re: [PATCH v2] net/intel: Replace manual array size calculation with ARRAY_SIZE
From: Przemek Kitszel @ 2026-04-23 7:41 UTC (permalink / raw)
To: Jakub Raczynski, error27; +Cc: netdev, kuba, anthony.l.nguyen, kernel-janitors
In-Reply-To: <20260422105710.268003-1-j.raczynski@samsung.com>
On 4/22/26 12:57, Jakub Raczynski wrote:
> There are still places in the code where manual calculation of array size
> exist, but it is good to enforce usage of single macro through the whole
> code as it makes code bit more readable.
> While at it, beautify condition surrounding it by reversing check and remove
> unnecessary casting.
>
thank you for the submission, please find some process-related feedback
from me
for future submissions for intel networking please target IWL (Intel
Wired Lan mailing list)
patches should be split into per-driver changes most of the time
please don't set "In-reply-to: v1" to v2 - just send as a standalone new
series (but link to v1 in changelog)
this is also a smallest bit above "too trivial to merge" IMO
finally this is not -net material, but -next, and -next is closed now
for PRs, and this is the only reason that warrants "v3" from you
(to:iwl, cc:netdev, after submission window reopens, ~Apr 27th)
(please collect Dan's Reviewed-by tag)
> Signed-off-by: Jakub Raczynski <j.raczynski@samsung.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_adminq.h | 2 +-
> drivers/net/ethernet/intel/iavf/iavf_adminq.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq.h b/drivers/net/ethernet/intel/i40e/i40e_adminq.h
> index 1be97a3a86ce..dcf3baec7b73 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_adminq.h
> +++ b/drivers/net/ethernet/intel/i40e/i40e_adminq.h
> @@ -109,7 +109,7 @@ static inline int i40e_aq_rc_to_posix(int aq_ret, int aq_rc)
> -EFBIG, /* I40E_AQ_RC_EFBIG */
> };
>
> - if (!((u32)aq_rc < (sizeof(aq_to_posix) / sizeof((aq_to_posix)[0]))))
> + if (aq_rc >= ARRAY_SIZE(aq_to_posix))
> return -ERANGE;
>
> return aq_to_posix[aq_rc];
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_adminq.h b/drivers/net/ethernet/intel/iavf/iavf_adminq.h
> index bbf5c4b3a2ae..dd2f61172157 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_adminq.h
> +++ b/drivers/net/ethernet/intel/iavf/iavf_adminq.h
> @@ -113,7 +113,7 @@ static inline int iavf_aq_rc_to_posix(int aq_ret, int aq_rc)
> if (aq_ret == IAVF_ERR_ADMIN_QUEUE_TIMEOUT)
> return -EAGAIN;
>
> - if (!((u32)aq_rc < (sizeof(aq_to_posix) / sizeof((aq_to_posix)[0]))))
> + if (aq_rc >= ARRAY_SIZE(aq_to_posix))
> return -ERANGE;
>
> return aq_to_posix[aq_rc];
^ 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