* Re: [PATCH v5 net] ax25: fix OOB read after address header strip in ax25_rcv()
From: David Laight @ 2026-04-21 8:41 UTC (permalink / raw)
To: Ashutosh Desai
Cc: netdev, linux-hams, jreuter, davem, edumazet, kuba, pabeni, horms,
linux-kernel, stable
In-Reply-To: <20260421054626.732399-1-ashutoshdesai993@gmail.com>
On Tue, 21 Apr 2026 05:46:26 +0000
Ashutosh Desai <ashutoshdesai993@gmail.com> wrote:
> A crafted AX.25 frame with a valid address header but no control byte
> causes skb->len to reach zero after skb_pull() strips the header.
> The subsequent reads of skb->data[0] (control) and skb->data[1] (PID)
> are then out of bounds.
>
> Linearize the skb after confirming the device is an AX.25 interface.
> Guard with skb->len < 1 after the pull - one byte suffices for LAPB
> control frames which have no PID byte. Add a separate skb->len < 2
> check inside the UI branch before accessing the PID byte.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com>
> ---
> v5:
> - Move skb_linearize() to after ax25_dev_ax25dev() check; avoids
> unnecessary allocation for frames on non-AX.25 interfaces
Nitpick: 'on interfaces where AX.25 isn't enabled'
They still have to be AX.25 frames and get discarded.
So they won't really be expected and any allocated memory is
immediately freed.
More relevant would be linearizing before the ax25_addr_parse() call.
In any case I suspect this code never sees non-linear packets.
The packets will all be short, I don't know ax25, but X.25 (which I've
implemented most of in the past) originally had an mtu of 128 bytes
(and real links running at 2400 baud).
David
> - Lower general guard from skb->len < 2 to skb->len < 1; the stricter
> limit incorrectly dropped valid 1-byte LAPB control frames (SABM,
> DISC, UA, DM, RR) which carry no PID byte
> - Add explicit skb->len < 2 check inside UI branch before the PID
> byte (skb->data[1]) access
> v4:
> - Linearize skb at entry to ax25_rcv(); replace pskb_may_pull() with
> skb->len < 2 check (per David Laight review)
> v3:
> - Remove incorrect Suggested-by; add Fixes:, Cc: stable@
> v2:
> - Replace skb->len check with pskb_may_pull(skb, 2)
>
> Link to v4: https://lore.kernel.org/netdev/20260417065407.206499-1-ashutoshdesai993@gmail.com/
> Link to v3: https://lore.kernel.org/netdev/20260415063654.3831353-1-ashutoshdesai993@gmail.com/
> Link to v2: https://lore.kernel.org/netdev/20260409152400.2219716-1-ashutoshdesai993@gmail.com/
> Link to v1: https://lore.kernel.org/netdev/20260409012235.2049389-1-ashutoshdesai993@gmail.com/
>
> net/ax25/ax25_in.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/net/ax25/ax25_in.c b/net/ax25/ax25_in.c
> index d75b3e9ed93d..c81d6830af48 100644
> --- a/net/ax25/ax25_in.c
> +++ b/net/ax25/ax25_in.c
> @@ -199,6 +199,9 @@ static int ax25_rcv(struct sk_buff *skb, struct net_device *dev,
> if ((ax25_dev = ax25_dev_ax25dev(dev)) == NULL)
> goto free;
>
> + if (skb_linearize(skb))
> + goto free;
> +
> /*
> * Parse the address header.
> */
> @@ -217,6 +220,9 @@ static int ax25_rcv(struct sk_buff *skb, struct net_device *dev,
> */
> skb_pull(skb, ax25_addr_size(&dp));
>
> + if (skb->len < 1)
> + goto free;
> +
> /* For our port addresses ? */
> if (ax25cmp(&dest, dev_addr) == 0 && dp.lastrepeat + 1 == dp.ndigi)
> mine = 1;
> @@ -227,6 +233,9 @@ static int ax25_rcv(struct sk_buff *skb, struct net_device *dev,
>
> /* UI frame - bypass LAPB processing */
> if ((*skb->data & ~0x10) == AX25_UI && dp.lastrepeat + 1 == dp.ndigi) {
> + if (skb->len < 2)
> + goto free;
> +
> skb_set_transport_header(skb, 2); /* skip control and pid */
>
> ax25_send_to_raw(&dest, skb, skb->data[1]);
^ permalink raw reply
* [PATCH 1/1] io_uring/zcrx: warn on freelist violations
From: Pavel Begunkov @ 2026-04-21 8:45 UTC (permalink / raw)
To: io-uring; +Cc: asml.silence, axboe, netdev
The freelist is appropriately sized to always be able to take a free
niov, but let's be more defensive and check the invariant with a
warning. That should help to catch any double-free issues.
Suggested-by: Kai Aizen <kai@snailsploit.com>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
---
io_uring/zcrx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/io_uring/zcrx.c b/io_uring/zcrx.c
index 2eb09219f0a0..7b93c87b8371 100644
--- a/io_uring/zcrx.c
+++ b/io_uring/zcrx.c
@@ -602,6 +602,8 @@ static void io_zcrx_return_niov_freelist(struct net_iov *niov)
struct io_zcrx_area *area = io_zcrx_iov_to_area(niov);
guard(spinlock_bh)(&area->freelist_lock);
+ if (WARN_ON_ONCE(area->free_count >= area->nia.num_niovs))
+ return;
area->freelist[area->free_count++] = net_iov_idx(niov);
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 net] net: ax25: fix integer overflow in ax25_rx_fragment()
From: Hugh Blemings @ 2026-04-21 8:45 UTC (permalink / raw)
To: Paolo Abeni, Mashiro Chen, netdev
Cc: linux-hams, kuba, horms, davem, edumazet, Jakub Kicinski, Greg KH
In-Reply-To: <805a8583-6a84-4dfb-a4d4-53f80f50effc@redhat.com>
Hi Paolo, All,
On 21/4/2026 17:29, Paolo Abeni wrote:
> On 4/13/26 10:49 PM, Mashiro Chen wrote:
>> ax25_rx_fragment() accumulates fragment lengths into ax25_cb->fraglen,
>> which is an unsigned short. When the total exceeds 65535, fraglen wraps
>> around to a small value. The subsequent alloc_skb(fraglen) allocates a
>> too-small buffer, and skb_put() in the copy loop triggers skb_over_panic().
>>
>> Add pskb_may_pull(skb, 1) at function entry to ensure the segmentation
>> header byte is in the linear data area before dereferencing skb->data.
>> This also rejects zero-length skbs, which the original code did not
>> check for.
>>
>> Two issues in the overflow error path are also fixed:
>> First, the current skb, after skb_pull(skb, 1), is neither enqueued
>> nor freed before returning 1, leaking it. Add kfree_skb(skb) before
>> the return.
>> Second, ax25->fraglen is not reset after skb_queue_purge(). Add
>> ax25->fraglen = 0 to restore a consistent state.
>>
>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>> Signed-off-by: Mashiro Chen <mashiro.chen@mailbox.org>
> we are moving ax25 out of tree:
>
> https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/
>
> please hold off until Thursday (after that our net PR will land into
> mainline), and eventually resend if the code still exists in Linus's
> tree at that point.
Is there any flexibility here ?
Jakubs (CC'd) patches to remove unfortunately weren't cross posted to
linux-hams and so I'm not able to directly reply in netdev
We've had a thread ongoing in linux-hams around the future of
AX25/ROSE/NETROM for the last week or so and believe we've a path
towards an orderly exit from the mainline tree, probably towards a
userspace implementation. This includes a couple of folks who have
indicated they would be open to overseeing the maintenance of the code
in the meantime.
We'd hoped to have a period of a few months to do an orderly exit from
the tree to minimise the impact on the (admittedly small, but non-zero)
users that build trees/make use of the in kernel support.
Apologies for my lack of familiarity with the process here to deprecate etc.
Cheers/73
Hugh
--
I am slowly moving to hugh@blemings.id.au as my main email address.
If you're using hugh@blemings.org please update your address book accordingly.
Thank you :)
^ permalink raw reply
* [PATCH 1/1] io_uring/zcrx: clear RQ headers on init
From: Pavel Begunkov @ 2026-04-21 8:46 UTC (permalink / raw)
To: io-uring; +Cc: asml.silence, axboe, netdev
It might be unexpected to users if the RQ head/tail after a ring
creation are not zeroed, fix that.
Cc: stable@vger.kernel.org
Fixes: 6f377873cb239 ("io_uring/zcrx: add interface queue and refill queue")
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
---
io_uring/zcrx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/io_uring/zcrx.c b/io_uring/zcrx.c
index fab3693ecb0d..2eb09219f0a0 100644
--- a/io_uring/zcrx.c
+++ b/io_uring/zcrx.c
@@ -396,6 +396,7 @@ static int io_allocate_rbuf_ring(struct io_ring_ctx *ctx,
ifq->rq.ring = (struct io_uring *)ptr;
ifq->rq.rqes = (struct io_uring_zcrx_rqe *)(ptr + off);
+ memset(ifq->rq.ring, 0, sizeof(*ifq->rq.ring));
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH 1/1] io_uring/zcrx: fix user_struct uaf
From: Pavel Begunkov @ 2026-04-21 8:47 UTC (permalink / raw)
To: io-uring; +Cc: asml.silence, axboe, netdev
io_free_rbuf_ring() usees a struct user_struct, which
io_zcrx_ifq_free() puts it down before destroying the ring.
Cc: stable@vger.kernel.org
Fixes: 5c686456a4e83 ("io_uring/zcrx: add user_struct and mm_struct to io_zcrx_ifq")
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
---
io_uring/zcrx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/io_uring/zcrx.c b/io_uring/zcrx.c
index 9a83d7eb4210..fab3693ecb0d 100644
--- a/io_uring/zcrx.c
+++ b/io_uring/zcrx.c
@@ -579,13 +579,13 @@ static void io_zcrx_ifq_free(struct io_zcrx_ifq *ifq)
if (ifq->area)
io_zcrx_free_area(ifq, ifq->area);
- free_uid(ifq->user);
if (ifq->mm_account)
mmdrop(ifq->mm_account);
if (ifq->dev)
put_device(ifq->dev);
io_free_rbuf_ring(ifq);
+ free_uid(ifq->user);
mutex_destroy(&ifq->pp_lock);
kfree(ifq);
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net v4 1/2] net/sched: taprio: fix NULL pointer dereference in class dump
From: Paolo Abeni @ 2026-04-21 8:49 UTC (permalink / raw)
To: Weiming Shi, jhs, vinicius.gomes, jiri, davem, edumazet, kuba,
shuah
Cc: horms, vladimir.oltean, xmei5, netdev, linux-kselftest
In-Reply-To: <20260416185501.647884-3-bestswngs@gmail.com>
On 4/16/26 8:55 PM, Weiming Shi wrote:
> @@ -2196,14 +2199,14 @@ static int taprio_graft(struct Qdisc *sch, unsigned long cl,
> *old = q->qdiscs[cl - 1];
> if (FULL_OFFLOAD_IS_ENABLED(q->flags)) {
> WARN_ON_ONCE(dev_graft_qdisc(dev_queue, new) != *old);
> - if (new)
> + if (new != &noop_qdisc)
> qdisc_refcount_inc(new);
> if (*old)
> qdisc_put(*old);
Unless I'm lost, it looks like taprio_leaf() can now return
`noop_qdisc`. As a consequence, `old` can be a valid qdisc, NULL or even
`noop_qdisc`. In the latter case it should not decrease the refcount, as
it was not increased previously.
/P
^ permalink raw reply
* Re: [PATCH 04/23] tick/nohz: Allow runtime changes in full dynticks CPUs
From: Thomas Gleixner @ 2026-04-21 8:50 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-5-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> Full dynticks can only be enabled if "nohz_full" boot option has been
> been specified with or without parameter. Any change in the list of
> nohz_full CPUs have to be reflected in tick_nohz_full_mask. Introduce
> a new tick_nohz_full_update_cpus() helper that can be called to update
> the tick_nohz_full_mask at run time. The housekeeping_update() function
> is modified to call the new helper when the HK_TYPE_KERNEL_NOSIE cpumask
> is going to be changed.
>
> We also need to enable CPU context tracking for those CPUs that
We need nothing. Use passive voice for change logs as requested in
documentation.
> are in tick_nohz_full_mask. So remove __init from tick_nohz_init()
> and ct_cpu_track_user() so that they be called later when an isolated
> cpuset partition is being created. The __ro_after_init attribute is
> taken away from context_tracking_key as well.
>
> Also add a new ct_cpu_untrack_user() function to reverse the action of
> ct_cpu_track_user() in case we need to disable the nohz_full mode of
> a CPU.
>
> With nohz_full enabled, the boot CPU (typically CPU 0) will be the
> tick CPU which cannot be shut down easily. So the boot CPU should not
> be used in an isolated cpuset partition.
>
> With runtime modification of nohz_full CPUs, tick_do_timer_cpu can become
> TICK_DO_TIMER_NONE. So remove the two TICK_DO_TIMER_NONE WARN_ON_ONCE()
> checks in tick-sched.c to avoid unnecessary warnings.
in tick-sched.c? Describe the functions which contain that.
> static inline void tick_nohz_task_switch(void)
> diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
> index 925999de1a28..394e432630a3 100644
> --- a/kernel/context_tracking.c
> +++ b/kernel/context_tracking.c
> @@ -411,7 +411,7 @@ static __always_inline void ct_kernel_enter(bool user, int offset) { }
> #define CREATE_TRACE_POINTS
> #include <trace/events/context_tracking.h>
>
> -DEFINE_STATIC_KEY_FALSE_RO(context_tracking_key);
> +DEFINE_STATIC_KEY_FALSE(context_tracking_key);
> EXPORT_SYMBOL_GPL(context_tracking_key);
>
> static noinstr bool context_tracking_recursion_enter(void)
> @@ -674,9 +674,9 @@ void user_exit_callable(void)
> }
> NOKPROBE_SYMBOL(user_exit_callable);
>
> -void __init ct_cpu_track_user(int cpu)
> +void ct_cpu_track_user(int cpu)
> {
> - static __initdata bool initialized = false;
> + static bool initialized;
>
> if (cpu == CONTEXT_TRACKING_FORCE_ENABLE) {
> static_branch_inc(&context_tracking_key);
> @@ -700,6 +700,15 @@ void __init ct_cpu_track_user(int cpu)
> initialized = true;
> }
>
> +void ct_cpu_untrack_user(int cpu)
> +{
> + if (!per_cpu(context_tracking.active, cpu))
> + return;
> +
> + per_cpu(context_tracking.active, cpu) = false;
> + static_branch_dec(&context_tracking_key);
> +}
> +
Why is this in a patch which makes tick/nohz related changes? This is a
preparatory change, so make it that way and do not bury it inside
something else.
> +/* Get the new set of run-time nohz CPU list & update accordingly */
> +void tick_nohz_full_update_cpus(struct cpumask *cpumask)
> +{
> + int cpu;
> +
> + if (!tick_nohz_full_running) {
> + pr_warn_once("Full dynticks cannot be enabled without the nohz_full kernel boot parameter!\n");
That's the result of this enforced enable hackery. Make this work
properly.
> + return;
> + }
> +
> + /*
> + * To properly enable/disable nohz_full dynticks for the affected CPUs,
> + * the new nohz_full CPUs have to be copied to tick_nohz_full_mask and
> + * ct_cpu_track_user/ct_cpu_untrack_user() will have to be called
> + * for those CPUs that have their states changed. Those CPUs should be
> + * in an offline state.
> + */
> + for_each_cpu_andnot(cpu, cpumask, tick_nohz_full_mask) {
> + WARN_ON_ONCE(cpu_online(cpu));
> + ct_cpu_track_user(cpu);
> + cpumask_set_cpu(cpu, tick_nohz_full_mask);
> + }
> +
> + for_each_cpu_andnot(cpu, tick_nohz_full_mask, cpumask) {
> + WARN_ON_ONCE(cpu_online(cpu));
> + ct_cpu_untrack_user(cpu);
> + cpumask_clear_cpu(cpu, tick_nohz_full_mask);
> + }
> +}
So this writes to tick_nohz_full_mask while other CPUs can access
it. That's just wrong and I'm not at all interested in the resulting
KCSAN warnings.
tick_nohz_full_mask needs to become a RCU protected pointer, which is
updated once the new mask is established in a separately allocated one.
Thanks,
tglx
^ permalink raw reply
* [PATCH net-next] nfp: fix swapped arguments in nfp_encode_basic_qdr() calls
From: Alexey Kodanev @ 2026-04-21 8:51 UTC (permalink / raw)
To: netdev
Cc: Jakub Kicinski, Simon Horman, Andrew Lunn, David S . Miller,
Eric Dumazet, Paolo Abeni, oss-drivers, Alexey Kodanev
There is a mismatch between the passed arguments and the actual
nfp_encode_basic_qdr() function parameters names:
static int nfp_encode_basic_qdr(u64 addr, int dest_island, int cpp_tgt,
int mode, bool addr40, int isld1,
int isld0)
{
...
But "dest_island" and "cpp_tgt" are swapped at every call-site.
For example:
return nfp_encode_basic_qdr(*addr, cpp_tgt, dest_island,
mode, addr40, isld1, isld0);
As a result, nfp_encode_basic_qdr() receives "dest_island" as CPP target
type, which is always NFP_CPP_TARGET_QDR(2) for these calls, and "cpp_tgt"
as the destination island ID, which can accidentally match or be outside
the valid NFP_CPP_TARGET_* types (e.g. '-1' for any destination).
Detected using the static analysis tool - Svace.
Fixes: 4cb584e0ee7d ("nfp: add CPP access core")
Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
---
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_target.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_target.c b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_target.c
index 79470f198a62..5c1edd143cee 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_target.c
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_target.c
@@ -493,7 +493,7 @@ static int nfp_encode_basic(u64 *addr, int dest_island, int cpp_tgt,
* the address but we can verify if the existing
* contents will point to a valid island.
*/
- return nfp_encode_basic_qdr(*addr, cpp_tgt, dest_island,
+ return nfp_encode_basic_qdr(*addr, dest_island, cpp_tgt,
mode, addr40, isld1, isld0);
iid_lsb = addr40 ? 34 : 26;
@@ -504,7 +504,7 @@ static int nfp_encode_basic(u64 *addr, int dest_island, int cpp_tgt,
return 0;
case 1:
if (cpp_tgt == NFP_CPP_TARGET_QDR && !addr40)
- return nfp_encode_basic_qdr(*addr, cpp_tgt, dest_island,
+ return nfp_encode_basic_qdr(*addr, dest_island, cpp_tgt,
mode, addr40, isld1, isld0);
idx_lsb = addr40 ? 39 : 31;
@@ -530,7 +530,7 @@ static int nfp_encode_basic(u64 *addr, int dest_island, int cpp_tgt,
* be set before hand and with them select an island.
* So we need to confirm that it's at least plausible.
*/
- return nfp_encode_basic_qdr(*addr, cpp_tgt, dest_island,
+ return nfp_encode_basic_qdr(*addr, dest_island, cpp_tgt,
mode, addr40, isld1, isld0);
/* Make sure we compare against isldN values
@@ -551,7 +551,7 @@ static int nfp_encode_basic(u64 *addr, int dest_island, int cpp_tgt,
* iid<1> = addr<30> = channel<0>
* channel<1> = addr<31> = Index
*/
- return nfp_encode_basic_qdr(*addr, cpp_tgt, dest_island,
+ return nfp_encode_basic_qdr(*addr, dest_island, cpp_tgt,
mode, addr40, isld1, isld0);
isld[0] &= ~3;
--
2.25.1
^ permalink raw reply related
* [PATCH net] net: airoha: Do not wake all netdev TX queues in airoha_qdma_wake_netdev_txqs()
From: Lorenzo Bianconi @ 2026-04-21 8:53 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
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>
^ permalink raw reply related
* Re: [PATCH net] netdevsim: Initialize all fields of ip header when building dummy sk_buff
From: Nikola Z. Ivanov @ 2026-04-21 8:54 UTC (permalink / raw)
To: Breno Leitao
Cc: kuba, andrew+netdev, davem, edumazet, pabeni, netdev,
linux-kernel
In-Reply-To: <aecyEArzjx8KRp8-@gmail.com>
On 4/21/26 11:19 AM, Breno Leitao wrote:
> On Tue, Apr 21, 2026 at 10:37:38AM +0300, Nikola Z. Ivanov wrote:
>> Syzbot reports a KMSAN uninit-value originating from
>> nsim_dev_trap_skb_build, with the allocation also
>> being performed in the same function.
>>
>> The cause of the KMSAN warning is a missing assignment of
>> the tos and id fields of the ip header.
>>
>> Fix this by calling skb_put_zero instead of skb_put to
>> guarantee null initialization.
>> Additionally remove the now redundant zero assignments
>> and reorder the remaining ones so that they more closely
>> match the order of the fields as they appear in the ip header.
>>
>> Closes: https://syzkaller.appspot.com/bug?extid=23d7fcd204e3837866ff
> How do you check in the report above that the missig un-initialized
> fields are "tos" and "id"?
>
> Thanks for the fix,
> --breno
Hi Breno,
I don't think it is visible here, my guess would
be because the checksum calculator walks the
header in small chunks instead of referencing
its fields.
The whole "KMSAN: uninit-value in irqentry_exit_to_kernel_mode_preempt"
doesn't really sound quite right.
Thank you!
^ permalink raw reply
* Re: [PATCH 05/23] tick: Pass timer tick job to an online HK CPU in tick_cpu_dying()
From: Thomas Gleixner @ 2026-04-21 8:55 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-6-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> In tick_cpu_dying(), if the dying CPU is the current timekeeper,
> it has to pass the job over to another CPU. The current code passes
> it to another online CPU. However, that CPU may not be a timer tick
> housekeeping CPU. If that happens, another CPU will have to manually
> take it over again later. Avoid this unnecessary work by directly
> assigning an online housekeeping CPU.
>
> Use READ_ONCE/WRITE_ONCE() to access tick_do_timer_cpu in case the
> non-HK CPUs may not be in stop machine in the future.
'may not be in the future' is yet more handwaving without
content. Please write your change logs in a way so that people who have
not spent months on this can follow.
> @@ -394,12 +395,19 @@ int tick_cpu_dying(unsigned int dying_cpu)
> {
> /*
> * If the current CPU is the timekeeper, it's the only one that can
> - * safely hand over its duty. Also all online CPUs are in stop
> - * machine, guaranteed not to be idle, therefore there is no
> + * safely hand over its duty. Also all online housekeeping CPUs are
> + * in stop machine, guaranteed not to be idle, therefore there is no
> * concurrency and it's safe to pick any online successor.
> */
> - if (tick_do_timer_cpu == dying_cpu)
> - tick_do_timer_cpu = cpumask_first(cpu_online_mask);
> + if (READ_ONCE(tick_do_timer_cpu) == dying_cpu) {
> + unsigned int new_cpu;
> +
> + guard(rcu)();
What's this guard for?
> + new_cpu = cpumask_first_and(cpu_online_mask, housekeeping_cpumask(HK_TYPE_TICK));
Why has this to use housekeeping_cpumask() and does not use
tick_nohz_full_mask?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 10/23] cpu: Use RCU to protect access of HK_TYPE_TIMER cpumask
From: Thomas Gleixner @ 2026-04-21 8:57 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-11-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> As HK_TYPE_TIMER cpumask is going to be changeable at run time, use
> RCU to protect access to the cpumask.
>
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
> kernel/cpu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index bc4f7a9ba64e..0d02b5d7a7ba 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -1890,6 +1890,8 @@ int freeze_secondary_cpus(int primary)
> cpu_maps_update_begin();
> if (primary == -1) {
> primary = cpumask_first(cpu_online_mask);
> +
> + guard(rcu)();
> if (!housekeeping_cpu(primary, HK_TYPE_TIMER))
> primary = housekeeping_any_cpu(HK_TYPE_TIMER);
housekeeping_cpu() and housekeeping_any_cpu() can operate on two
different CPU masks once the runtime update is enabled.
Seriously?
^ permalink raw reply
* Re: [PATCH 11/23] hrtimer: Use RCU to protect access of HK_TYPE_TIMER cpumask
From: Thomas Gleixner @ 2026-04-21 8:59 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-12-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> As HK_TYPE_TIMER cpumask is going to be changeable at run time, use
As the ...
> RCU to protect access to the cpumask.
>
> The access of HK_TYPE_TIMER cpumask within hrtimers_cpu_dying() is
> protected as interrupt is disabled and all the other CPUs are stopped
interrupts are disabled
> when this function is invoked as part of the CPU tear down process.
^ permalink raw reply
* [PATCH 0/2] mfd: rsmu_spi: fixes and new IC support
From: Matthew Bystrin @ 2026-04-21 9:07 UTC (permalink / raw)
To: Lee Jones, Richard Cochran, Min Li; +Cc: linux-kernel, netdev
Greetings!
First patch fixes Renesas 8A34002 SPI driver.
In my setup 8A34002 is connected to VisionFive2 via SPI. I've discovered that
upstream driver does not work:
[ 4.728771] 8a3400x-phc 8a3400x-phc.0.auto: 4.8.7, Id: 0x4002 HW Rev: 5 OTP Config Select: 0
[ 4.737389] 8a3400x-phc 8a3400x-phc.0.auto: requesting firmware 'idtcm.bin'
[ 4.744462] 8a3400x-phc 8a3400x-phc.0.auto: Direct firmware load for idtcm.bin failed with error -2
[ 4.753547] 8a3400x-phc 8a3400x-phc.0.auto: Failed at line 1273 in idtcm_load_firmware!
[ 4.761576] 8a3400x-phc 8a3400x-phc.0.auto: loading firmware failed with -2
[ 4.769411] 8a3400x-phc 8a3400x-phc.0.auto: No wait state: DPLL_SYS_STATE 0
[ 4.776374] 8a3400x-phc 8a3400x-phc.0.auto: Continuing while SYS APLL/DPLL is not locked
[ 4.785206] 8a3400x-phc 8a3400x-phc.0.auto: Unsupported MANUAL_REFERENCE: 0x00
[ 4.796930] 8a3400x-phc 8a3400x-phc.0.auto: PLL2 registered as ptp0
This being caused by a piece of code in rsmu_write_page_register() function:
if (reg < RSMU_CM_SCSR_BASE)
return 0;
All addresses in include/linux/mfd/idt8a340_reg.h are less than
RSMU_CM_SCSR_BASE so function was returning early, before any modifications to
the page register. Valid read of versions - is just a coincidence, because
default value of the page register is zero.
There were 2 separate patch series which have to be merged in one time: mfd and
ptp. The latter have been merged, the former[1] have not. As result we've got a
broken driver.
This patch can be reverted later when the second part will be ready (of course
if it is planned to do so). Any comments, Min? I could support with testing.
Also I've had a quick look into I2C part. It may also require the same kind of
fixes to work properly. But I didn't tested it. I could do some experiments and
return with patches later.
Second patch just adds support for 8A34002, which is compatible with 8A34001. As
I can see there is no need to update bindings, everything is already being done.
Link: https://lore.kernel.org/netdev/LV3P220MB1202F8E2FCCFBA2519B4966EA0192@LV3P220MB1202.NAMP220.PROD.OUTLOOK.COM/
Signed-off-by: Matthew Bystrin <dev.mbstr@gmail.com>
Matthew Bystrin (2):
mfd: rsmu_spi: fix page register setup
mfd: rsmu_spi: add 8a34002 support
drivers/mfd/rsmu_spi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH 1/2] mfd: rsmu_spi: fix page register setup
From: Matthew Bystrin @ 2026-04-21 9:07 UTC (permalink / raw)
To: Lee Jones, Richard Cochran, Min Li; +Cc: linux-kernel, netdev
In-Reply-To: <20260421090710.395591-1-dev.mbstr@gmail.com>
Fix writes to page register in 8A3400x family (Clock Matrix).
All calls to rsmu_write_page_register() have resulted in early return,
becase all addresses in include/linux/mfd/idt8a340_reg.h are less than
RSMU_CM_SCSR_BASE.
There were 2 separate patch series which have to be merged in one time:
mfd and ptp. The latter have been merged, the former[1] have not.
Link: https://lore.kernel.org/netdev/LV3P220MB1202F8E2FCCFBA2519B4966EA0192@LV3P220MB1202.NAMP220.PROD.OUTLOOK.COM/
Fixes: 67d6c76fc815 ("mfd: rsmu: Support 32-bit address space")
Signed-off-by: Matthew Bystrin <dev.mbstr@gmail.com>
---
drivers/mfd/rsmu_spi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mfd/rsmu_spi.c b/drivers/mfd/rsmu_spi.c
index 39d9be1e141f..55c5698e7e77 100644
--- a/drivers/mfd/rsmu_spi.c
+++ b/drivers/mfd/rsmu_spi.c
@@ -101,11 +101,9 @@ static int rsmu_write_page_register(struct rsmu_ddata *rsmu, u32 reg)
switch (rsmu->type) {
case RSMU_CM:
- /* Do not modify page register for none-scsr registers */
- if (reg < RSMU_CM_SCSR_BASE)
- return 0;
page_reg = RSMU_CM_PAGE_ADDR;
page = reg & RSMU_PAGE_MASK;
+ page |= RSMU_CM_SCSR_BASE;
buf[0] = (u8)(page & 0xFF);
buf[1] = (u8)((page >> 8) & 0xFF);
buf[2] = (u8)((page >> 16) & 0xFF);
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] mfd: rsmu_spi: add 8a34002 support
From: Matthew Bystrin @ 2026-04-21 9:07 UTC (permalink / raw)
To: Lee Jones, Richard Cochran, Min Li; +Cc: linux-kernel, netdev
In-Reply-To: <20260421090710.395591-1-dev.mbstr@gmail.com>
Add separate compatible string and spi_devcie_id to support 8a34002.
Signed-off-by: Matthew Bystrin <dev.mbstr@gmail.com>
---
drivers/mfd/rsmu_spi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mfd/rsmu_spi.c b/drivers/mfd/rsmu_spi.c
index 55c5698e7e77..2d4ad9606aec 100644
--- a/drivers/mfd/rsmu_spi.c
+++ b/drivers/mfd/rsmu_spi.c
@@ -242,6 +242,7 @@ static void rsmu_spi_remove(struct spi_device *client)
static const struct spi_device_id rsmu_spi_id[] = {
{ "8a34000", RSMU_CM },
{ "8a34001", RSMU_CM },
+ { "8a34002", RSMU_CM },
{ "82p33810", RSMU_SABRE },
{ "82p33811", RSMU_SABRE },
{}
@@ -251,6 +252,7 @@ MODULE_DEVICE_TABLE(spi, rsmu_spi_id);
static const struct of_device_id rsmu_spi_of_match[] = {
{ .compatible = "idt,8a34000", .data = (void *)RSMU_CM },
{ .compatible = "idt,8a34001", .data = (void *)RSMU_CM },
+ { .compatible = "idt,8a34002", .data = (void *)RSMU_CM },
{ .compatible = "idt,82p33810", .data = (void *)RSMU_SABRE },
{ .compatible = "idt,82p33811", .data = (void *)RSMU_SABRE },
{}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 16/23] genirq/cpuhotplug: Use RCU to protect access of HK_TYPE_MANAGED_IRQ cpumask
From: Thomas Gleixner @ 2026-04-21 9:02 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-17-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> As HK_TYPE_MANAGED_IRQ cpumask is going to be changeable at run time,
> use RCU to protect access to the cpumask.
>
> To enable the new HK_TYPE_MANAGED_IRQ cpumask to take effect, the
> following steps can be done.
Can be done?
> 1) Update the HK_TYPE_MANAGED_IRQ cpumask to take out the newly isolated
> CPUs and add back the de-isolated CPUs.
> 2) Tear down the affected CPUs to cause irq_migrate_all_off_this_cpu()
> to be called on the affected CPUs to migrate the irqs to other
> HK_TYPE_MANAGED_IRQ housekeeping CPUs.
> 3) Bring up the previously offline CPUs to invoke
> irq_affinity_online_cpu() to allow the newly de-isolated CPUs to
> be used for managed irqs.
Which previously offline CPUs?
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 2e8072437826..8270c4de260b 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -263,6 +263,7 @@ int irq_do_set_affinity(struct irq_data *data, const struct cpumask *mask, bool
> housekeeping_enabled(HK_TYPE_MANAGED_IRQ)) {
> const struct cpumask *hk_mask;
>
> + guard(rcu)();
> hk_mask = housekeeping_cpumask(HK_TYPE_MANAGED_IRQ);
>
> cpumask_and(tmp_mask, mask, hk_mask);
How is this hunk related to $Subject?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH iwl-net v2 0/4] iavf: fix VLAN filter state machine races
From: Simon Horman @ 2026-04-21 9:02 UTC (permalink / raw)
To: Petr Oros
Cc: netdev, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jesse Brandeburg, Mitch Williams, Aaron Brown,
Przemyslaw Patynowski, Jedrzej Jagielski, intel-wired-lan,
linux-kernel, jacob.e.keller
In-Reply-To: <cover.1776426683.git.poros@redhat.com>
On Fri, Apr 17, 2026 at 04:29:41PM +0200, Petr Oros wrote:
> The iavf VLAN filter state machine has several design issues that lead
> to race conditions between userspace add/del calls and the watchdog
> task's virtchnl processing. Filters can get lost or leak HW resources,
> especially during interface down/up cycles and namespace moves.
...
Hi Petr,
Sashiko has a bit to say about this patch.
I'd appreciate it if you could look over that.
In particular, the feedback on patches 2 and 3 may warrant
some updates to this patchset, while I think 4 is more
in the realm of possible future work.
^ permalink raw reply
* Re: [RFC PATCH 1/2] kernel/notifier: replace single-linked list with double-linked list for reverse traversal
From: Petr Mladek @ 2026-04-21 9:05 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: chensong_2000, rafael, lenb, mturquette, sboyd, viresh.kumar, agk,
snitzer, mpatocka, bmarzins, song, yukuai, linan122, jason.wessel,
danielt, dianders, horms, davem, edumazet, kuba, pabeni, paulmck,
frederic, mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin,
jpoimboe, jikos, mbenes, joe.lawrence, rostedt, mark.rutland,
mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, linux-acpi, linux-clk, linux-pm,
live-patching, dm-devel, linux-raid, kgdb-bugreport, netdev
In-Reply-To: <20260420144429.57b45f2beece690bceea96ec@kernel.org>
On Mon 2026-04-20 14:44:29, Masami Hiramatsu wrote:
> Hi Song,
>
> On Wed, 15 Apr 2026 15:01:37 +0800
> chensong_2000@189.cn wrote:
>
> > From: Song Chen <chensong_2000@189.cn>
> >
> > The current notifier chain implementation uses a single-linked list
> > (struct notifier_block *next), which only supports forward traversal
> > in priority order. This makes it difficult to handle cleanup/teardown
> > scenarios that require notifiers to be called in reverse priority order.
>
> What about introducing a new notification callback API that allows you
> to describe dependencies between callback functions?
>
> For example, when registering a callback, you could register a string
> as an ID and specify whether to call it before or after that ID,
> or you could register a comparison function that is called when adding
> to a list. (I prefer @name and @depends fields so that it can be easily
> maintained.)
This looks too complex. It would make sense only
when this API has more users.
Also this won't be enough for the ftrace/livepatch callbacks.
They need to be ordered against against each other. But they
also need to be called before/after all other callbacks.
For example, when the module is loaded:
+ 1st frace
+ 2nd livepatch
+ then other notifiers
See the commit c1bf08ac26e92122 ("ftrace: Be first to run code
modification on modules").
> This would allow for better dependency building when adding to the list.
> >
> > A concrete example is the ordering dependency between ftrace and
> > livepatch during module load/unload. see the detail here [1].
>
> If this only concerns notification callback issues with the ftrace
> and livepatch modules, it's far more robust to simply call the
> necessary processing directly when the modules load and unload,
> rather than registering notification callbacks externally.
>
> There are fprobe, kprobe and its trace-events, all of them are using
> ftrace as its fundation layer. In this case, I always needs to
> consider callback order when a module is unloaded.
>
> If ftrace is working as a part of module callbacks, it will conflict
> with fprobe/kprobe module callback. Of course we can reorder it with
> modifying its priority. But this is ugly, because when we introduce
> a new other feature which depends on another layer, we need to
> reorder the callback's priority number on the list.
>
> Based on the above, I don't think this can be resolved simply by
> changing the list of notification callbacks to a bidirectional list.
I agree. I would keep it as is (hardcoded).
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH net v3 1/1] net: l3mdev: Reject non-L3 uppers in slave helpers
From: Ido Schimmel @ 2026-04-21 9:10 UTC (permalink / raw)
To: Ren Wei
Cc: netdev, idosch, dsahern, davem, edumazet, kuba, pabeni, horms,
jiri, yifanwucs, tomapufckgml, yuantan098, bird, royenheart
In-Reply-To: <20260420182640.GA1027405@shredder>
On Mon, Apr 20, 2026 at 09:26:50PM +0300, Ido Schimmel wrote:
> On Mon, Apr 20, 2026 at 02:32:08PM +0300, Ido Schimmel wrote:
> > On Sun, Apr 19, 2026 at 10:53:32PM +0800, Ren Wei wrote:
> > > From: Haoze Xie <royenheart@gmail.com>
> > >
> > > Several l3mdev slave-side helpers resolve an upper device and then use
> > > l3mdev_ops without first proving that the resolved device is still a
> > > valid L3 master.
> > >
> > > During slave transition, an RCU reader can transiently observe an upper
> > > that is not an L3 master. Guard the affected slave-resolved paths by
> > > requiring the resolved upper to still be an L3 master before using
> > > l3mdev_ops, while keeping existing L3 RX handler providers intact.
> > >
> > > Fixes: fdeea7be88b1 ("net: vrf: Set slave's private flag before linking")
> > > Cc: stable@kernel.org
> > > Reported-by: Yifan Wu <yifanwucs@gmail.com>
> > > Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> > > Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> > > Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> > > Suggested-by: Xin Liu <bird@lzu.edu.cn>
> > > Tested-by: Haoze Xie <royenheart@gmail.com>
> > > Signed-off-by: Haoze Xie <royenheart@gmail.com>
> > > Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
> >
> > I think it's fine for net:
> >
> > Reviewed-by: Ido Schimmel <idosch@nvidia.com>
>
> Thought about this again. I would like to check another approach
> (synchronize_net() after clearing IFF_L3MDEV_SLAVE). Will update
> tomorrow.
Sorry about the back and forth, but I thought about it again last night
and I think that this is a better fix:
https://github.com/idosch/linux/commit/e67517758ebcddf8a1b97817e4ab0fbf82f467fe.patch
It's a minimal fix in the control plane of the VRF driver which doesn't
add more checks in the data path. I can submit it later this week unless
there are objections.
^ permalink raw reply
* Re: [PATCH net] netdevsim: Initialize all fields of ip header when building dummy sk_buff
From: Breno Leitao @ 2026-04-21 9:12 UTC (permalink / raw)
To: Nikola Z. Ivanov
Cc: kuba, andrew+netdev, davem, edumazet, pabeni, netdev,
linux-kernel
In-Reply-To: <9ce273bd-6912-4442-8672-4c89bebf32ed@gmail.com>
On Tue, Apr 21, 2026 at 11:54:19AM +0300, Nikola Z. Ivanov wrote:
> On 4/21/26 11:19 AM, Breno Leitao wrote:
> > On Tue, Apr 21, 2026 at 10:37:38AM +0300, Nikola Z. Ivanov wrote:
> > >
> > > Closes: https://syzkaller.appspot.com/bug?extid=23d7fcd204e3837866ff
> >
> > How do you check in the report above that the missig un-initialized
> > fields are "tos" and "id"?
>
> I don't think it is visible here, my guess would
> be because the checksum calculator walks the
> header in small chunks instead of referencing
> its fields.
>
> The whole "KMSAN: uninit-value in irqentry_exit_to_kernel_mode_preempt"
> doesn't really sound quite right.
That's precisely my question - how does this fix relate to that specific
report?
Were you able to reproduce the KMSAN report?
Thanks for the quick answer,
--breno
^ permalink raw reply
* Re: [PATCH net-deletions] net: remove unused ATM protocols and legacy ATM device drivers
From: David Woodhouse @ 2026-04-21 9:26 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, skhan,
linux, tsbogend, maddy, mpe, npiggin, chleroy, 3chas3, razor,
idosch, jani.nikula, mchehab+huawei, tytso, herbert, geert,
ebiggers, johannes.berg, jonathan.cameron, kees, kuniyu,
fourier.thomas, andriy.shevchenko, rdunlap, akpm, linux-doc,
linux-mips, linuxppc-dev, bridge
In-Reply-To: <20260421021943.1295109-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]
On Mon, 2026-04-20 at 19:19 -0700, Jakub Kicinski wrote:
> Remove the ATM protocol modules and PCI/SBUS ATM device drivers
> that are no longer in active use.
>
> The ATM core protocol stack, PPPoATM, and USB DSL modem drivers
> (drivers/usb/atm/) are retained in-tree to maintain PPP over ATM
> (PPPoA) support for DSL connections.
>
> Removed ATM protocol modules:
> - net/atm/clip.c - Classical IP over ATM (RFC 2225)
> - net/atm/br2684.c - RFC 2684 bridged protocols
I believe PPPoE over BR2684 is also used on ADSL lines.
https://git.kernel.org/torvalds/c/ae088d663bee strongly seems to imply
that I used to use it myself, or at least was *able* to switch to it
for testing (although I could have sworn I mostly used PPPoA).
> - net/atm/lec.c - LAN Emulation Client (LANE)
> - net/atm/mpc.c, mpoa_caches.c, mpoa_proc.c - Multi-Protocol Over ATM
>
> Removed PCI/SBUS ATM device drivers (drivers/atm/):
> - adummy, atmtcp - software/testing ATM devices
> - eni - Efficient Networks ENI155P (OC-3, ~1995)
> - fore200e - FORE Systems 200E PCI/SBUS (OC-3, ~1999)
> - he - ForeRunner HE (OC-3/OC-12, ~2000)
> - idt77105 - IDT 77105 25 Mbps ATM PHY
> - idt77252 - IDT 77252 NICStAR II (OC-3, ~2000)
> - iphase - Interphase ATM PCI (OC-3/DS3/E3)
> - lanai - Efficient Networks Speedstream 3010
> - nicstar - IDT 77201 NICStAR (155/25 Mbps, ~1999)
> - solos-pci - Traverse Technologies ADSL2+ PCI (defunct vendor)
Traverse still exists: https://traverse.com.au/
I suspect they don't have a huge amount of interest in the Solos any
more, or the Geode-based SBC they sold with two of them on-board. But
OpenWrt does still support them, and I even have one here (although no
ADSL line to test it with). They were briefly popular as fully Linux-
supported ADSL routers.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH 1/9] bitfield: add FIELD_GET_SIGNED()
From: David Laight @ 2026-04-21 9:27 UTC (permalink / raw)
To: Yury Norov
Cc: Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Andy Lutomirski,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Ping-Ke Shih, Richard Cochran, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexandre Belloni,
Yury Norov, Rasmus Villemoes, Hans de Goede, Linus Walleij,
Sakari Ailus, Salah Triki, Achim Gratz, Ben Collins, linux-kernel,
linux-iio, linux-wireless, netdev, linux-rtc
In-Reply-To: <aeZocbNjbvzMZO8b@yury>
On Mon, 20 Apr 2026 13:54:57 -0400
Yury Norov <ynorov@nvidia.com> wrote:
> On Mon, Apr 20, 2026 at 01:19:40PM +0200, Peter Zijlstra wrote:
> > On Fri, Apr 17, 2026 at 01:36:12PM -0400, Yury Norov wrote:
> > > The bitfields are designed in assumption that fields contain unsigned
> > > integer values, thus extracting the values from the field implies
> > > zero-extending.
> > >
> > > Some drivers need to sign-extend their fields, and currently do it like:
> > >
> > > dc_re += sign_extend32(FIELD_GET(0xfff000, tmp), 11);
> > > dc_im += sign_extend32(FIELD_GET(0xfff, tmp), 11);
> > >
> > > It's error-prone because it relies on user to provide the correct
> > > index of the most significant bit and proper 32 vs 64 function flavor.
> > >
> > > Thus, introduce a FIELD_GET_SIGNED() macro, which is the more
> > > convenient and compiles (on x86_64) to just a couple instructions:
> > > shl and sar.
> > >
> > > Signed-off-by: Yury Norov <ynorov@nvidia.com>
> > > ---
> > > include/linux/bitfield.h | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> > > index 54aeeef1f0ec..35ef63972810 100644
> > > --- a/include/linux/bitfield.h
> > > +++ b/include/linux/bitfield.h
> > > @@ -178,6 +178,22 @@
> > > __FIELD_GET(_mask, _reg, "FIELD_GET: "); \
> > > })
> > >
> > > +/**
> > > + * FIELD_GET_SIGNED() - extract a signed bitfield element
> > > + * @mask: shifted mask defining the field's length and position
> > > + * @reg: value of entire bitfield
> > > + *
> > > + * Returns the sign-extended field specified by @_mask from the
> > > + * bitfield passed in as @_reg by masking and shifting it down.
> > > + */
> > > +#define FIELD_GET_SIGNED(mask, reg) \
> > > + ({ \
> > > + __BF_FIELD_CHECK(mask, reg, 0U, "FIELD_GET_SIGNED: "); \
> > > + ((__signed_scalar_typeof(mask))((long long)(reg) << \
> > > + __builtin_clzll(mask) >> (__builtin_clzll(mask) + \
> > > + __builtin_ctzll(mask))));\
> > > + })
> >
> > IIRC clz is count-leading-zeros and ctz is count-trailing-zeros. Most of
> > the other FIELD things use __bf_shf() which is defined in terms of ffs -
> > 1 (which is another way of writing ctz).
> >
> > So how about you start by redefining __bf_shf() in ctz, and then add
> > another helper for the clz and write the thing something like:
> >
> > ((long long)(reg) << __bf_clz(mask)) >> (__bf_clz(mask) + __bf_shf(mask));
>
> So...
>
> I like the shorter form, but whatever we add in the bitfield.h - we'll
> have to support it.
>
> For example, __bf_shf() wasn't intended to be used outsize of the
> header, thus double underscored. But there's over 100 external users
> now. And to make it worse, it's broken for GCC 14 and earlier:
For anyone who hasn't followed the gory details it isn't 'very broken'.
Basically __builtin_ffsll() doesn't always generate an 'integer constant
expression' from constant input so you can get a compile fail.
> https://lore.kernel.org/all/20260409-field-prep-fix-v1-1-f0e9ae64f63c@imgtec.com/
>
> So needs to get fixed.
>
> The bitfield.h has two __bf macros: __bf_shf() and __bf_cast_unsigned().
> They are thin wrappers,
__bf_cast_unsigned() isn't exactly thin.
David
> but after all do something with the corresponding
> builtins output. The __bf_cls() would be a pure renaming. I'm OK with
> that, but some people don't:
>
> https://lore.kernel.org/all/20260303182845.250bb2de@kernel.org/
>
> That's why I didn't make FIELD_GET_SIGNED() implementation looking nicer.
> If you strongly prefer the shorter version, I can do that in v2.
>
> > Also, since the order of the shifts is rather important, I think it
> > makes sense to add this extra pair of (), even when not strictly needed,
> > just to make it easier to read.
>
> Sure, will do.
>
^ permalink raw reply
* Re: [PATCH] ieee802154: ca8210: fix cas_ctl leak on spi_async failure
From: Markus Elfring @ 2026-04-21 9:47 UTC (permalink / raw)
To: Shitalkumar Gandhi, linux-wpan, netdev, Alexander Aring,
Miquel Raynal, Stefan Schmidt
Cc: Shitalkumar Gandhi, stable, LKML, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
In-Reply-To: <20260421073259.2259783-1-shitalkumar.gandhi@cambiumnetworks.com>
…
> Fix it by freeing cas_ctl on the spi_async() error path. While here,
> correct the misleading error string: the function calls spi_async(),
> not spi_sync().
Would it be safer to offer desired changes as separate patches?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v7.0#n81
Regards,
Markus
^ permalink raw reply
* [PATCH net] net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels
From: Andrea Mayer @ 2026-04-21 9:47 UTC (permalink / raw)
To: davem, dsahern, edumazet, kuba, pabeni, horms
Cc: bigeasy, clrkwllms, rostedt, david.lebrun, alex.aring,
stefano.salsano, andrea.mayer, netdev, linux-rt-devel,
linux-kernel, stable
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
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")
Cc: stable@vger.kernel.org
Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
---
net/ipv6/rpl_iptunnel.c | 9 +++++++++
net/ipv6/seg6_iptunnel.c | 9 +++++++++
2 files changed, 18 insertions(+)
diff --git a/net/ipv6/rpl_iptunnel.c b/net/ipv6/rpl_iptunnel.c
index c7942cf65567..4e10adcd70e8 100644
--- a/net/ipv6/rpl_iptunnel.c
+++ b/net/ipv6/rpl_iptunnel.c
@@ -287,7 +287,16 @@ static int rpl_input(struct sk_buff *skb)
if (!dst) {
ip6_route_input(skb);
+
+ /* ip6_route_input() sets a NOREF dst; force a refcount on it
+ * before caching or further use.
+ */
+ skb_dst_force(skb);
dst = skb_dst(skb);
+ if (unlikely(!dst)) {
+ err = -ENETUNREACH;
+ goto drop;
+ }
/* cache only if we don't create a dst reference loop */
if (!dst->error && lwtst != dst->lwtstate) {
diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index 97b50d9b1365..94284b483be0 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -515,7 +515,16 @@ static int seg6_input_core(struct net *net, struct sock *sk,
if (!dst) {
ip6_route_input(skb);
+
+ /* ip6_route_input() sets a NOREF dst; force a refcount on it
+ * before caching or further use.
+ */
+ skb_dst_force(skb);
dst = skb_dst(skb);
+ if (unlikely(!dst)) {
+ err = -ENETUNREACH;
+ goto drop;
+ }
/* cache only if we don't create a dst reference loop */
if (!dst->error && lwtst != dst->lwtstate) {
--
2.20.1
^ 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