* Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?
From: Hugh Blemings @ 2026-04-21 6:28 UTC (permalink / raw)
To: Steve Conklin; +Cc: Stuart Longland VK4MSL, Dan Cross, linux-hams, netdev
In-Reply-To: <CALJxBtX_T8sv11ank-arLfoVqJqXegi3D_ZT9ZFbMHkuf-2RAg@mail.gmail.com>
Hi All,
Just to note in this thread (top posting as it's a bit orthogonal to the
rest of this discussion) that events have preceeded us somewhat here
A patch just recently submitted removes the AX25, NETROM and ROSE code
from the kernel moving it to the mod-orphan sub tree of netdev
https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/T/#u
A shame but perhaps inevitable - but I think we have a good plan
unfolding to both take care of medium term maintenance of the kernel
code (in tree or out as it may be) as well as a move to userspace in the
longer term.
For the benefit of the netdev readership - we had a thread over in
linux-hams on this but that may not have been visible to folks in
netdev. TL;DR: we think we have a way forward but appreciate this may
not be quick enough to meet the requirements/concerns put forward
If we can delay removal, that'd be grand, but appreciate that moment may
have passed.
Cheers/73
Hugh
VK3YYZ/AD5RV
On 20/4/2026 02:18, Steve Conklin wrote:
> On Sun, Apr 19, 2026 at 4:36 AM Hugh Blemings <hugh@blemings.org> wrote:
>> HI All,
>>
>> On 19/4/2026 14:01, Stuart Longland VK4MSL wrote:
>>> On 19/4/26 05:28, Dan Cross wrote:
>>>> [Top-posting to make meta-commendary]
>>>>
>>>> I wonder if other folks have thoughts, here? It doesn't bode well that
>>>> the discussion hasn't progressed. 🙁
>>> I haven't had a chance to fully review what you've posted… there was a
>>> lot of historical information in there including detail on the
>>> protocols in question. I've earmarked it to go through closely
>>> however. (e.g. I had heard of "ROSE" but never seen a spec for it.)
>>>
>>> My situation was wanting a library that I could use to do AX.25
>>> networking from userspace without having applications having to
>>> elevate to `root` to achieve it. There was also a maintenance
>>> concern. Rather than try and work out the AX.25 kernel stack, I opted
>>> to instead build my own.
>>>
>>> Instructive, but difficult as the documentation is sketchy in places.
>>>
>>> My implementation was written in Python 3.5+ for ease of development.
>>> Probably not the best option, but it got the job done. `aioax25`
>>> allowed me to deliver a project for an emergency comms group and
>>> provides a reasonable foundation for simple tasks. The stack is also
>>> portable to other platforms. (I mostly only care about Linux and
>>> *BSD, but well written software should work elsewhere too. Apparently
>>> it works fine on Apple MacOS X.)
>>>
>>> A userspace AX.25 daemon which implements the stack would seem to be
>>> the best course of action, but the elephant in the room is what the
>>> API would look like.
>>>
>>> The only thing I've seen close to achieving something like that would
>>> be the AGWPE protocol, however the author of that AX.25 stack has
>>> categorically stated that he "owns" that protocol. I don't feel like
>>> going to court to argue copyright of interfaces for the sake of a hobby.
>>>
>>> The AGWPE protocol is also very limiting: a lot of fields in the AX.25
>>> frame are not accessible via this protocol, either for reading or
>>> setting. Want to use the two reserved bits to signal something in a
>>> custom protocol? Too bad.
>>>
>>> I was therefore pondering a "stream"-like protocol using KISS-style
>>> framing (to re-use existing code). The frames would serve as an RPC
>>> mechanism for implementing something like the `libax25` API, exposing
>>> the same functionality and allowing an application to interact with
>>> the AX.25 stack without having to implement the whole protocol (as
>>> they'd have to do with KISS).
>>>
>>> Client applications could connect either via Unix domain sockets or TCP.
>>>
>>> You mention the performance hit of crossing the kernel/user-space
>>> boundary… I think Direwolf experimentally can work as high as
>>> 38400bps. A turn-of-the-century desktop PC was easily able to keep up
>>> with that for PPP links (with `pppd` running in userspace). ARMv7
>>> single board computers made 15 years later can deliver similar
>>> performance. I don't think this will be much of a bottleneck in
>>> practice.
>>>
>>> I think userspace is the right way forward given the niche use case here.
>> Apologies, I kicked off this thread and life intervened a bit and have
>> only now had a chance to get back to read through the excellent
>> discourse since.
>>
>> I did have one off list conversation about this which was similarly
>> leaning towards a well managed/discussed shift to a userspace approach.
>> The individual in question has had quite a lot of both ham radio and
>> FOSS experience - I'll give them a nudge and see if they would be
>> willing to weigh in here too as I think they'd add a lot to the thread.
>>
>> I wonder if anyone on list feels they have the right skills to put
>> together the shim/compatibility library that would be needed to allow
>> the kernel code to be removed? Seems like that might be the next thing
>> to explore ?
>>
>> Hoping things settle down a bit and will be able to contribute more to
>> ongoing discussion
>>
>> vy 73
>> Hugh
>> VK1YYZ/AD5RV
>>
>>
>>
>> --
>> 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 :)
>>
>>
> Hi all,
>
> I'm another former maintainer who has been less active in the FOSS
> hamm community for a while. Thanks for all the history, and it's been
> great to see familiar names and callsigns again.
> /wave
>
> My personal take is that moving to userspace is the right long-term
> goal. As for deciding the exact form that takes, this thread is a good
> start.
>
> I'd like to make an offer for a long-term home for these components.
>
> I'm a director at ORI (Open Research Institute), and ORI could be a
> home for these. We're a project-based, completely open and volunteer
> nonprofit focused on ham radio and communications. We have volunteers
> with FOSS and ham radio experience, and we're already set up with a
> GitHub org, slack chat, and the infrastructure to manage projects.
>
> https://www.openresearch.institute/
> https://www.openresearch.institute/your-project-is-welcome/
>
> Anyone who currently maintains or has an interest in this is welcome
> to participate there.
> I personally volunteer to help move development infrastructure to ORI,
> if that's the wish of the community.
>
> Steve Conklin AI4QR
>
--
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 net] net: airoha: fix BQL imbalance in TX path
From: Lorenzo Bianconi @ 2026-04-21 6:35 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,
Lorenzo Bianconi
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>
^ permalink raw reply related
* RE: [Intel-wired-lan] [PATCH iwl-next v5] igb: Retrieve Tx timestamp from BH workqueue
From: Rinitha, SX @ 2026-04-21 6:37 UTC (permalink / raw)
To: Kurt Kanzenbach, Nguyen, Anthony L, Kitszel, Przemyslaw
Cc: Paul Menzel, Vadim Fedorenko, Gomes, Vinicius,
netdev@vger.kernel.org, Richard Cochran,
linux-kernel@vger.kernel.org, Loktionov, Aleksandr, Andrew Lunn,
Eric Dumazet, intel-wired-lan@lists.osuosl.org, Keller, Jacob E,
Jakub Kicinski, Paolo Abeni, David S. Miller,
Sebastian Andrzej Siewior
In-Reply-To: <20260305-igb_irq_ts-v5-1-d3b96828ab5b@linutronix.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Kurt Kanzenbach
> Sent: 05 March 2026 15:56
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>
> Cc: Paul Menzel <pmenzel@molgen.mpg.de>; Vadim Fedorenko <vadim.fedorenko@linux.dev>; Gomes, Vinicius <vinicius.gomes@intel.com>; netdev@vger.kernel.org; Richard Cochran <richardcochran@gmail.com>; Kurt Kanzenbach <kurt@linutronix.de>; linux-kernel@vger.kernel.org; Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>; Eric Dumazet <edumazet@google.com>; intel-wired-lan@lists.osuosl.org; Keller, Jacob E <jacob.e.keller@intel.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S. Miller <davem@davemloft.net>; Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Subject: [Intel-wired-lan] [PATCH iwl-next v5] igb: Retrieve Tx timestamp from BH workqueue
>
> Retrieve Tx timestamp from system BH instead of regular system workqueue.
>
> The current implementation uses schedule_work() which is executed by the system work queue and kworkers to retrieve Tx timestamps. This increases latency and can lead to timeouts in case of heavy system load. i210 is often used in industrial systems, where timestamp timeouts can be fatal.
>
> Therefore, switch to the system BH workqueues which are executed in softirq context shortly after the IRQ handler returns.
>
>Tested between Intel i210 and i350 with ptp4l gPTP profile:
>
> |ptp4l[30.405]: rms 4 max 7 freq +12825 +/- 3 delay 247 +/- 0
> |ptp4l[31.406]: rms 2 max 3 freq +12829 +/- 3 delay 248 +/- 0
>|ptp4l[32.406]: rms 3 max 3 freq +12827 +/- 3 delay 248 +/- 0
> |ptp4l[33.406]: rms 2 max 3 freq +12827 +/- 3 delay 248 +/- 0
> |ptp4l[34.407]: rms 3 max 6 freq +12825 +/- 4 delay 248 +/- 0
> |ptp4l[35.407]: rms 3 max 6 freq +12822 +/- 4 delay 246 +/- 0
> |ptp4l[36.407]: rms 7 max 10 freq +12812 +/- 5 delay 248 +/- 0
> |ptp4l[37.408]: rms 5 max 8 freq +12808 +/- 3 delay 248 +/- 0
>
> Furthermore, Miroslav Lichvar tested with ntpperf and chrony on Intel i350:
>
> Without the patch:
>
> | | responses | response time (ns)
> |rate clients | lost invalid basic xleave | min mean max stddev
> |150000 15000 0.00% 0.00% 0.00% 100.00% +4188 +36475 +193328 16179
> |157500 15750 0.02% 0.00% 0.02% 99.96% +6373 +42969 +683894 22682
> |165375 16384 0.03% 0.00% 0.00% 99.97% +7911 +43960 +692471 24454
> |173643 16384 0.06% 0.00% 0.00% 99.94% +8323 +45627 +707240 28452
> |182325 16384 0.06% 0.00% 0.00% 99.94% +8404 +47292 +722524 26936
> |191441 16384 0.00% 0.00% 0.00% 100.00% +8930 +51738 +223727 14272
> |201013 16384 0.05% 0.00% 0.00% 99.95% +9634 +53696 +776445 23783
> |211063 16384 0.00% 0.00% 0.00% 100.00% +14393 +54558 +329546 20473
> |221616 16384 2.59% 0.00% 0.05% 97.36% +23924 +321205 +518192 21838
> |232696 16384 7.00% 0.00% 0.10% 92.90% +33396 +337709 +575661 21017
> |244330 16384 10.82% 0.00% 0.15% 89.03% +34188 +340248 +556237 20880
> |
> |With the patch:
> |150000 15000 5.11% 0.00% 0.00% 94.88% +4426 +460642 +640884 83746
> |157500 15750 11.54% 0.00% 0.26% 88.20% +14434 +543656 +738355 30349
> |165375 16384 15.61% 0.00% 0.31% 84.08% +35822 +515304 +833859 25596
> |173643 16384 19.58% 0.00% 0.37% 80.05% +20762 +568962 +900100 28118
> |182325 16384 23.46% 0.00% 0.42% 76.13% +41829 +547974 +804170 27890
> |191441 16384 27.23% 0.00% 0.46% 72.31% +15182 +557920 +798212 28868
> |201013 16384 30.51% 0.00% 0.49% 69.00% +15980 +560764 +805576 29979
> |211063 16384 0.06% 0.00% 0.00% 99.94% +12668 +80487 +410555 62182
> |221616 16384 2.94% 0.00% 0.05% 97.00% +21587 +342769 +517566 23359
> |232696 16384 6.94% 0.00% 0.10% 92.96% +16581 +336068 +484574 18453
> |244330 16384 11.45% 0.00% 0.14% 88.41% +23608 +345023 +564130 19177
>
> There are some minor differences at lower rates, but no performance regressions at higher ones.
>
> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
> ---
> Changes in v5:
> - Adjust changelog wording (Aleksandr Loktionov)
> - Include measurement numbers in changelog (Paul Menzel)
> - Link to v4: https://patch.msgid.link/20260303-igb_irq_ts-v4-1-cbae7f127061@linutronix.de
>
> Changes in v4:
> - Use BH workqueue (tasklet) instead of doing timestamping in IRQ path (Jakub Kicinski)
> - Link to v3: https://patch.msgid.link/20260205-igb_irq_ts-v3-1-2efc7bc4b885@linutronix.de
>
> Changes in v3:
> - Switch back to IRQ, but for i210 only
> - Keep kworker for all other NICs like i350 (Miroslav)
> - Link to v2: https://lore.kernel.org/r/20250822-igb_irq_ts-v2-1-1ac37078a7a4@linutronix.de
>
> Changes in v2:
> - Switch from IRQ to PTP aux worker due to NTP performance regression (Miroslav)
> - Link to v1: https://lore.kernel.org/r/20250815-igb_irq_ts-v1-1-8c6fc0353422@linutronix.de
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 4 ++-- drivers/net/ethernet/intel/igb/igb_ptp.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* [PATCH net] net: airoha: stop net_device TX queue before updating CPU index
From: Lorenzo Bianconi @ 2026-04-21 6:43 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev,
Lorenzo Bianconi
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>
^ permalink raw reply related
* Re: [patch 32/38] powerpc/spufs: Use mftb() directly
From: Mukesh Kumar Chaurasiya @ 2026-04-21 6:48 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Michael Ellerman, linuxppc-dev, Arnd Bergmann, x86,
Lu Baolu, iommu, Michael Grzeschik, netdev, linux-wireless,
Herbert Xu, linux-crypto, Vlastimil Babka, linux-mm,
David Woodhouse, Bernie Thompson, linux-fbdev, Theodore Tso,
linux-ext4, Andrew Morton, Uladzislau Rezki, Marco Elver,
Dmitry Vyukov, kasan-dev, Andrey Ryabinin, Thomas Sailer,
linux-hams, Jason A. Donenfeld, Richard Henderson, linux-alpha,
Russell King, linux-arm-kernel, Catalin Marinas, Huacai Chen,
loongarch, Geert Uytterhoeven, linux-m68k, Dinh Nguyen,
Jonas Bonn, linux-openrisc, Helge Deller, linux-parisc,
Paul Walmsley, linux-riscv, Heiko Carstens, linux-s390,
David S. Miller, sparclinux
In-Reply-To: <20260410120319.723429844@kernel.org>
On Fri, Apr 10, 2026 at 02:21:04PM +0200, Thomas Gleixner wrote:
> There is no reason to indirect via get_cycles(), which is about to be
> removed.
>
> Use mftb() directly.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> arch/powerpc/platforms/cell/spufs/switch.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> --- a/arch/powerpc/platforms/cell/spufs/switch.c
> +++ b/arch/powerpc/platforms/cell/spufs/switch.c
> @@ -34,6 +34,7 @@
> #include <asm/spu_priv1.h>
> #include <asm/spu_csa.h>
> #include <asm/mmu_context.h>
> +#include <asm/time.h>
>
> #include "spufs.h"
>
> @@ -279,7 +280,7 @@ static inline void save_timebase(struct
> * Read PPE Timebase High and Timebase low registers
> * and save in CSA. TBD.
> */
> - csa->suspend_time = get_cycles();
> + csa->suspend_time = mftb();
> }
>
> static inline void remove_other_spu_access(struct spu_state *csa,
> @@ -1261,7 +1262,7 @@ static inline void setup_decr(struct spu
> * in LSCSA.
> */
> if (csa->priv2.mfc_control_RW & MFC_CNTL_DECREMENTER_RUNNING) {
> - cycles_t resume_time = get_cycles();
> + cycles_t resume_time = mftb();
> cycles_t delta_time = resume_time - csa->suspend_time;
>
> csa->lscsa->decr_status.slot[0] = SPU_DECR_STATUS_RUNNING;
>
Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com>
^ permalink raw reply
* [PATCH 6.6.y] i40e: Fix preempt count leak in napi poll tracepoint
From: charles_xu @ 2026-04-21 7:18 UTC (permalink / raw)
To: tglx, anthony.l.nguyen, przemyslaw.kitszel, intel-wired-lan,
netdev, joe, aleksandr.loktionov, stable
From: Thomas Gleixner <tglx@kernel.org>
[ Upstream commit 4b3d54a85bd37ebf2d9836f0d0de775c0ff21af9 ]
Using get_cpu() in the tracepoint assignment causes an obvious preempt
count leak because nothing invokes put_cpu() to undo it:
softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101?
This clearly has seen a lot of testing in the last 3+ years...
Use smp_processor_id() instead.
Fixes: 6d4d584a7ea8 ("i40e: Add i40e_napi_poll tracepoint")
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
Cc: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org
Reviewed-by: Joe Damato <joe@dama.to>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Charles Xu <charles_xu@189.cn>
---
drivers/net/ethernet/intel/i40e/i40e_trace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_trace.h b/drivers/net/ethernet/intel/i40e/i40e_trace.h
index 33b4e30f5e00..9b735a9e2114 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_trace.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_trace.h
@@ -88,7 +88,7 @@ TRACE_EVENT(i40e_napi_poll,
__entry->rx_clean_complete = rx_clean_complete;
__entry->tx_clean_complete = tx_clean_complete;
__entry->irq_num = q->irq_num;
- __entry->curr_cpu = get_cpu();
+ __entry->curr_cpu = smp_processor_id();
__assign_str(qname, q->name);
__assign_str(dev_name, napi->dev ? napi->dev->name : NO_DEV);
__assign_bitmask(irq_affinity, cpumask_bits(&q->affinity_mask),
--
2.35.3
^ permalink raw reply related
* Re: [PATCH net v2 2/2] selftests/bpf: check epoll readiness after reuseport migration
From: Kuniyuki Iwashima @ 2026-04-21 7:15 UTC (permalink / raw)
To: jt26wzz
Cc: davem, dsahern, edumazet, horms, kuba, kuniyu, linux-kernel,
linux-kselftest, ncardwell, netdev, pabeni, shuah, tamird
In-Reply-To: <20260418181333.1713389-3-jt26wzz@gmail.com>
From: Zhenzhong Wu <jt26wzz@gmail.com>
Date: Sun, 19 Apr 2026 02:13:33 +0800
> After migrate_dance() moves established children to the target
> listener, add it to an epoll set and verify that epoll_wait(..., 0)
> reports it ready before accept().
>
> This adds epoll coverage for the TCP_ESTABLISHED reuseport migration
> case in migrate_reuseport.
>
> Keep the check limited to TCP_ESTABLISHED cases. TCP_SYN_RECV and
> TCP_NEW_SYN_RECV still depend on asynchronous handshake completion,
> so a zero-timeout epoll_wait() would race there.
>
> Signed-off-by: Zhenzhong Wu <jt26wzz@gmail.com>
> ---
> .../bpf/prog_tests/migrate_reuseport.c | 32 ++++++++++++++++++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c b/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
> index 653b0a20f..580a53424 100644
> --- a/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
> +++ b/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
> @@ -18,13 +18,16 @@
> * 9. call shutdown() for the second server
> * and migrate the requests in the accept queue
> * to the last server socket.
> - * 10. call accept() for the last server socket.
> + * 10. for TCP_ESTABLISHED cases, call epoll_wait(..., 0)
> + * for the last server socket.
> + * 11. call accept() for the last server socket.
> *
> * Author: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
> */
>
> #include <bpf/bpf.h>
> #include <bpf/libbpf.h>
> +#include <sys/epoll.h>
>
> #include "test_progs.h"
> #include "test_migrate_reuseport.skel.h"
> @@ -522,6 +525,33 @@ static void run_test(struct migrate_reuseport_test_case *test_case,
> goto close_clients;
> }
>
> + /* Only TCP_ESTABLISHED has already-migrated accept-queue entries
> + * here. Later states still depend on follow-up handshake work.
> + */
> + if (test_case->state == BPF_TCP_ESTABLISHED) {
> + struct epoll_event ev = {
> + .events = EPOLLIN,
> + };
> + int epfd;
> + int nfds;
> +
> + epfd = epoll_create1(EPOLL_CLOEXEC);
> + if (!ASSERT_NEQ(epfd, -1, "epoll_create1"))
> + goto close_clients;
> +
> + ev.data.fd = test_case->servers[MIGRATED_TO];
> + if (!ASSERT_OK(epoll_ctl(epfd, EPOLL_CTL_ADD,
> + test_case->servers[MIGRATED_TO], &ev),
> + "epoll_ctl"))
> + goto close_epfd;
> +
> + nfds = epoll_wait(epfd, &ev, 1, 0);
> + ASSERT_EQ(nfds, 1, "epoll_wait");
Thanks for the update, but the test passes without patch 1.
I think it would be best to test just after shutdown()
where migration happens.
Also, TCP_SYN_RECV should be covered in the same way.
---8<---
diff --git a/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c b/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
index 580a534249a7..66fea936649e 100644
--- a/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
+++ b/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
@@ -353,8 +353,29 @@ static int update_maps(struct migrate_reuseport_test_case *test_case,
static int migrate_dance(struct migrate_reuseport_test_case *test_case)
{
+ struct epoll_event ev = {
+ .events = EPOLLIN,
+ };
+ int epoll, nfds;
int i, err;
+ if (test_case->state != BPF_TCP_NEW_SYN_RECV) {
+ epoll = epoll_create1(0);
+ if (!ASSERT_NEQ(epoll, -1, "epoll_create1"))
+ return -1;
+
+ ev.data.fd = test_case->servers[MIGRATED_TO];
+ if (!ASSERT_OK(epoll_ctl(epoll, EPOLL_CTL_ADD,
+ test_case->servers[MIGRATED_TO], &ev),
+ "epoll_ctl")) {
+ goto close_epoll;
+ }
+
+ nfds = epoll_wait(epoll, &ev, 1, 0);
+ if (!ASSERT_EQ(nfds, 0, "epoll_wait 1"))
+ goto close_epoll;
+ }
+
/* Migrate TCP_ESTABLISHED and TCP_SYN_RECV requests
* to the last listener based on eBPF.
*/
@@ -368,6 +389,15 @@ static int migrate_dance(struct migrate_reuseport_test_case *test_case)
if (test_case->state == BPF_TCP_NEW_SYN_RECV)
return 0;
+ nfds = epoll_wait(epoll, &ev, 1, 0);
+ if (!ASSERT_EQ(nfds, 1, "epoll_wait 2")) {
+close_epoll:
+ close(epoll);
+ return -1;
+ }
+
+ close(epoll);
+
/* Note that we use the second listener instead of the
* first one here.
*
@@ -525,33 +555,6 @@ static void run_test(struct migrate_reuseport_test_case *test_case,
goto close_clients;
}
- /* Only TCP_ESTABLISHED has already-migrated accept-queue entries
- * here. Later states still depend on follow-up handshake work.
- */
- if (test_case->state == BPF_TCP_ESTABLISHED) {
- struct epoll_event ev = {
- .events = EPOLLIN,
- };
- int epfd;
- int nfds;
-
- epfd = epoll_create1(EPOLL_CLOEXEC);
- if (!ASSERT_NEQ(epfd, -1, "epoll_create1"))
- goto close_clients;
-
- ev.data.fd = test_case->servers[MIGRATED_TO];
- if (!ASSERT_OK(epoll_ctl(epfd, EPOLL_CTL_ADD,
- test_case->servers[MIGRATED_TO], &ev),
- "epoll_ctl"))
- goto close_epfd;
-
- nfds = epoll_wait(epfd, &ev, 1, 0);
- ASSERT_EQ(nfds, 1, "epoll_wait");
-
-close_epfd:
- close(epfd);
- }
-
count_requests(test_case, skel);
close_clients:
---8<---
^ permalink raw reply related
* Re: [EXTERNAL] Re: [PATCH net v2] hv_sock: Report EOF instead of -EIO for FIN
From: Stefano Garzarella @ 2026-04-21 7:28 UTC (permalink / raw)
To: Dexuan Cui
Cc: patchwork-bot+netdevbpf@kernel.org, kuba@kernel.org,
KY Srinivasan, Haiyang Zhang, wei.liu@kernel.org, Long Li,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
horms@kernel.org, niuxuewei.nxw@antgroup.com,
linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Ben Hillis, levymitchell0@gmail.com
In-Reply-To: <SA1PR21MB69214CABCA0DCD597040F849BF2C2@SA1PR21MB6921.namprd21.prod.outlook.com>
On Tue, 21 Apr 2026 at 05:13, Dexuan Cui <DECUI@microsoft.com> wrote:
>
> > From: patchwork-bot+netdevbpf@kernel.org <patchwork-
> > bot+netdevbpf@kernel.org>
> > Sent: Monday, April 20, 2026 3:00 PM
> > > [...]
> >
> > Here is the summary with links:
> > - [net,v2] hv_sock: Report EOF instead of -EIO for FIN
> > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f63152958994
>
> Hi Jakub, Stefano,
> I'm sorry -- I just posted v3
> https://lore.kernel.org/linux-hyperv/20260421025950.1099495-1-decui@microsoft.com/T/#u
> and then I realized that the v2 had been merged into the main branch :-(
>
> Should I post a new delta patch(with a Fixes tag against the v2) based on the main branch?
Ehm, I'm not sure about the process but if it's merged in net tree,
maybe we need a follow up patch.
Anyway, let's wait for Jakub's or other net maintainers' suggestions.
Thanks,
Stefano
^ permalink raw reply
* Re: [PATCH v4 net] net: ax25: fix integer overflow in ax25_rx_fragment()
From: Paolo Abeni @ 2026-04-21 7:29 UTC (permalink / raw)
To: Mashiro Chen, netdev; +Cc: linux-hams, kuba, horms, davem, edumazet
In-Reply-To: <20260413204921.70463-1-mashiro.chen@mailbox.org>
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.
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH net v2] ipv6: Apply max_dst_opts_cnt to ip6_tnl_parse_tlv_enc_lim
From: Daniel Borkmann @ 2026-04-21 7:33 UTC (permalink / raw)
To: Justin Iurman, Ido Schimmel
Cc: kuba, edumazet, dsahern, tom, willemdebruijn.kernel, pabeni,
netdev
In-Reply-To: <524def33-63e1-47c0-be38-dee68d859332@gmail.com>
On 4/20/26 8:55 PM, Justin Iurman wrote:
> On 4/19/26 16:31, Ido Schimmel wrote:
>> On Sun, Apr 19, 2026 at 12:37:35AM +0200, Justin Iurman wrote:
>>> Nope. But if it happens, users would be confused as max_dst_opts_cnt would
>>> not have the same meaning in two different code paths. OTOH, I agree that
>>> such situation would look suspicious. I guess it's fine to keep your patch
>>> as is and to not over-complicate things unnecessarily.
>>
>> I agree that it's weird to reuse max_dst_opts_cnt here:
>>
>> 1. The meaning is different from the Rx path.
>>
>> 2. We only enforce max_dst_opts_cnt, but not max_dst_opts_len.
>>
>> 3. The default is derived from the initial netns, unlike in the Rx path.
>>
>> Given the above and that:
>>
>> 1. We believe that 8 options until the tunnel encapsulation limit option
>> is liberal enough.
>>
>> 2. We don't want to over-complicate things.
>>
>> Can we go with an hard coded 8 and see if anyone complains? In the
>> unlikely case that someone complains we can at least gain some insight
>> into how this option is actually used with tunnels.
>
> In general, I'm not a big fan of hard-coded values, but I also think that in this context it would make sense to do so. This is not a strong +1, let's say it's more a "not against it".
Makes sense, I'll update it in a v3.
^ permalink raw reply
* [PATCH] ieee802154: ca8210: fix cas_ctl leak on spi_async failure
From: Shitalkumar Gandhi @ 2026-04-21 7:32 UTC (permalink / raw)
To: alex.aring, stefan, miquel.raynal
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-wpan, netdev,
linux-kernel, stable, Shitalkumar Gandhi
ca8210_spi_transfer() allocates cas_ctl with kzalloc_obj(GFP_ATOMIC)
and relies entirely on the SPI completion callback
ca8210_spi_transfer_complete() to free it.
The spi_async() API only invokes the completion callback on successful
submission. On failure it returns a negative error code without ever
queuing the callback, which leaves cas_ctl and its embedded spi_message
and spi_transfer orphaned. Every kfree(cas_ctl) in the driver is
inside the completion callback, so there is no other reclamation path.
ca8210_spi_transfer() is called from ca8210_spi_exchange(), the
interrupt handler ca8210_interrupt_handler(), and from the retry path
inside the completion callback itself. The exchange and interrupt
handler paths loop on -EBUSY, so under sustained SPI bus contention
every retry iteration leaks a fresh cas_ctl (~600 bytes per
occurrence).
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().
Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
Cc: stable@vger.kernel.org
Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com>
---
drivers/net/ieee802154/ca8210.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
index ed4178155a5d..bf837adfebb2 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -919,9 +919,10 @@ static int ca8210_spi_transfer(
if (status < 0) {
dev_crit(
&spi->dev,
- "status %d from spi_sync in write\n",
+ "status %d from spi_async in write\n",
status
);
+ kfree(cas_ctl);
}
return status;
--
2.25.1
^ permalink raw reply related
* [PATCH 6.1.y] net: dsa: clean up FDB, MDB, VLAN entries on unbind
From: Alva Lan @ 2026-04-21 7:36 UTC (permalink / raw)
To: gregkh, sashal, stable; +Cc: netdev, Vladimir Oltean, Jakub Kicinski, Alva Lan
From: Vladimir Oltean <vladimir.oltean@nxp.com>
[ Upstream commit 7afb5fb42d4950f33af2732b8147c552659f79b7 ]
As explained in many places such as commit b117e1e8a86d ("net: dsa:
delete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written given
the assumption that higher layers have balanced additions/deletions.
As such, it only makes sense to be extremely vocal when those
assumptions are violated and the driver unbinds with entries still
present.
But Ido Schimmel points out a very simple situation where that is wrong:
https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/
(also briefly discussed by me in the aforementioned commit).
Basically, while the bridge bypass operations are not something that DSA
explicitly documents, and for the majority of DSA drivers this API
simply causes them to go to promiscuous mode, that isn't the case for
all drivers. Some have the necessary requirements for bridge bypass
operations to do something useful - see dsa_switch_supports_uc_filtering().
Although in tools/testing/selftests/net/forwarding/local_termination.sh,
we made an effort to popularize better mechanisms to manage address
filters on DSA interfaces from user space - namely macvlan for unicast,
and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the
fact is that 'bridge fdb add ... self static local' also exists as
kernel UAPI, and might be useful to someone, even if only for a quick
hack.
It seems counter-productive to block that path by implementing shim
.ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPP
in order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() from
running, although we could do that.
Accepting that cleanup is necessary seems to be the only option.
Especially since we appear to be coming back at this from a different
angle as well. Russell King is noticing that the WARN_ON() triggers even
for VLANs:
https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/
What happens in the bug report above is that dsa_port_do_vlan_del() fails,
then the VLAN entry lingers on, and then we warn on unbind and leak it.
This is not a straight revert of the blamed commit, but we now add an
informational print to the kernel log (to still have a way to see
that bugs exist), and some extra comments gathered from past years'
experience, to justify the logic.
Fixes: 0832cd9f1f02 ("net: dsa: warn if port lists aren't empty in dsa_port_teardown")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://patch.msgid.link/20250414212930.2956310-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[ Apply the patch to net/dsa/dsa2.c in v6.1 since commit
47d2ce03dcfb ("net: dsa: rename dsa2.c back into dsa.c and create its header")
renamed this file to net/dsa/dsa.c starting from v6.2. ]
Signed-off-by: Alva Lan <alvalan9@foxmail.com>
---
net/dsa/dsa2.c | 38 +++++++++++++++++++++++++++++++++++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 415e856ba0ac..9ecb5e34e484 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -1738,12 +1738,44 @@ static int dsa_switch_parse(struct dsa_switch *ds, struct dsa_chip_data *cd)
static void dsa_switch_release_ports(struct dsa_switch *ds)
{
+ struct dsa_mac_addr *a, *tmp;
struct dsa_port *dp, *next;
+ struct dsa_vlan *v, *n;
dsa_switch_for_each_port_safe(dp, next, ds) {
- WARN_ON(!list_empty(&dp->fdbs));
- WARN_ON(!list_empty(&dp->mdbs));
- WARN_ON(!list_empty(&dp->vlans));
+ /* These are either entries that upper layers lost track of
+ * (probably due to bugs), or installed through interfaces
+ * where one does not necessarily have to remove them, like
+ * ndo_dflt_fdb_add().
+ */
+ list_for_each_entry_safe(a, tmp, &dp->fdbs, list) {
+ dev_info(ds->dev,
+ "Cleaning up unicast address %pM vid %u from port %d\n",
+ a->addr, a->vid, dp->index);
+ list_del(&a->list);
+ kfree(a);
+ }
+
+ list_for_each_entry_safe(a, tmp, &dp->mdbs, list) {
+ dev_info(ds->dev,
+ "Cleaning up multicast address %pM vid %u from port %d\n",
+ a->addr, a->vid, dp->index);
+ list_del(&a->list);
+ kfree(a);
+ }
+
+ /* These are entries that upper layers have lost track of,
+ * probably due to bugs, but also due to dsa_port_do_vlan_del()
+ * having failed and the VLAN entry still lingering on.
+ */
+ list_for_each_entry_safe(v, n, &dp->vlans, list) {
+ dev_info(ds->dev,
+ "Cleaning up vid %u from port %d\n",
+ v->vid, dp->index);
+ list_del(&v->list);
+ kfree(v);
+ }
+
list_del(&dp->list);
kfree(dp);
}
--
2.43.0
^ permalink raw reply related
* [PATCH net] netdevsim: Initialize all fields of ip header when building dummy sk_buff
From: Nikola Z. Ivanov @ 2026-04-21 7:37 UTC (permalink / raw)
To: kuba, andrew+netdev, davem, edumazet, pabeni
Cc: netdev, linux-kernel, Nikola Z. Ivanov
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
Fixes: da58f90f11f5 ("netdevsim: Add devlink-trap support")
Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com>
---
There is a very similar function in psample.c called nsim_dev_psample_skb_build
which is almost identical to nsim_dev_trap_skb_build except for the
allocation flag reflecting its non-interrupt context and the fact
it does proper initialization of all fields.
Since these 2 are almost identical would it make sense to combine them
into 1, possbly by passing the allocation flags as parameters?
Thank you in advance for reviewing and answering!
drivers/net/netdevsim/dev.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/netdevsim/dev.c b/drivers/net/netdevsim/dev.c
index 1e06e781c835..64b7cc3a6575 100644
--- a/drivers/net/netdevsim/dev.c
+++ b/drivers/net/netdevsim/dev.c
@@ -829,16 +829,14 @@ static struct sk_buff *nsim_dev_trap_skb_build(void)
skb->protocol = htons(ETH_P_IP);
skb_set_network_header(skb, skb->len);
- iph = skb_put(skb, sizeof(struct iphdr));
- iph->protocol = IPPROTO_UDP;
- iph->saddr = in_aton("192.0.2.1");
- iph->daddr = in_aton("198.51.100.1");
- iph->version = 0x4;
- iph->frag_off = 0;
+ iph = skb_put_zero(skb, sizeof(struct iphdr));
iph->ihl = 0x5;
+ iph->version = 0x4;
iph->tot_len = htons(tot_len);
iph->ttl = 100;
- iph->check = 0;
+ iph->protocol = IPPROTO_UDP;
+ iph->saddr = in_aton("192.0.2.1");
+ iph->daddr = in_aton("198.51.100.1");
iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl);
skb_set_transport_header(skb, skb->len);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net] ipv6: Implement limits on extension header parsing
From: Daniel Borkmann @ 2026-04-21 7:38 UTC (permalink / raw)
To: Justin Iurman, Eric Dumazet
Cc: kuba, dsahern, tom, willemdebruijn.kernel, idosch, pabeni, netdev
In-Reply-To: <e084bf5d-99bf-4e23-8dc1-3e7e13c58a2e@gmail.com>
On 4/18/26 4:15 PM, Justin Iurman wrote:
> On 4/18/26 15:46, Justin Iurman wrote:
>> On 4/18/26 15:15, Eric Dumazet wrote:
>>> On Sat, Apr 18, 2026 at 5:50 AM Justin Iurman <justin.iurman@gmail.com> wrote:
>>>> On 4/18/26 14:26, Daniel Borkmann wrote:
>>>>> On 4/18/26 1:45 PM, Justin Iurman wrote:
>>>>>> On 4/17/26 19:18, Daniel Borkmann wrote:
>>>>> [...]
>>>>>>> diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
>>>>>>> index d2cd33e2698d..93f865545a7c 100644
>>>>>>> --- a/net/ipv6/sysctl_net_ipv6.c
>>>>>>> +++ b/net/ipv6/sysctl_net_ipv6.c
>>>>>>> @@ -135,6 +135,14 @@ static struct ctl_table ipv6_table_template[] = {
>>>>>>> .extra1 = SYSCTL_ZERO,
>>>>>>> .extra2 = &flowlabel_reflect_max,
>>>>>>> },
>>>>>>> + {
>>>>>>> + .procname = "max_ext_hdrs_number",
>>>>>>> + .data = &init_net.ipv6.sysctl.max_ext_hdrs_cnt,
>>>>>>> + .maxlen = sizeof(int),
>>>>>>> + .mode = 0644,
>>>>>>> + .proc_handler = proc_dointvec_minmax,
>>>>>>> + .extra1 = SYSCTL_ONE,
>>>>>>> + },
>>>>>>> {
>>>>>>> .procname = "max_dst_opts_number",
>>>>>>> .data = &init_net.ipv6.sysctl.max_dst_opts_cnt,
>>>>>>
>>>>>> NACKed-by: Justin Iurman <justin.iurman@gmail.com>
>>>>>>
>>>>>> +1000 on the need, but NAK on the way it is done. IMO, we don't want
>>>>>> yet-another-sysctl for that. Instead, we have (well, not yet, but it's
>>>>>> about time) this series [1] to enforce ordering and occurrences of
>>>>>> Extension Headers, which is based on an IETF draft [2] (FYI, draft-
>>>>>> ietf-6man-eh-limits is dead). I think we should enforce ordering and
>>>>>> occurrences in this code path too, instead of relying on a sysctl.
>>>>>> Let's keep both code paths consistent.
>>>>
>>>>> Hm, that series [1] should probably go to net instead of net-next, but atm
>>>>
>>>> +1, would make sense.
>>>>
>>>>> hasn't moved since a month. I'd still think max_ext_hdrs_number would be
>>>>> useful given it has less complexity also for stable, but I guess ultimately
>>>>> up to maintainers..
>>>>
>>>> In the short term, I agree. What worries me is that we end up with a
>>>> redundant, or even useless, sysctl once the other series is applied,
>>>> which will only increase user confusion.
>>>
>>> Given the amount of bugs in this code, a sysctl is safe and quire reasonable.
>>>
>>> No one will object when it is eventually removed (or has no action)
>>>
>>> For the record, I approve Daniel patch.
>>
>> Fair enough. If there is consensus on this patch, then let me just suggest two changes:
>>
>> - make it clear in the sysctl description that it mainly applies to TX (as opposed to the other series [1] discussed earlier that applies to RX)
>
> Sorry, I meant it does not apply to core RX (ip6_rcv()), which is what series [1] does.
>
>> - set the default to 8 (which should be the max value) instead of 32, as per RFC8200, Sec. 4.
Ok, I'll switch to use 8 as a default limit and I'm looking to also cover ip6_rcv()
path as well in the next revision given its also affected but less severe as the
icmp6 path.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH RFC net-next v2 2/2] af_packet: Add port specific handling for HSR
From: Willem de Bruijn @ 2026-04-21 7:41 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, Willem de Bruijn
Cc: netdev, (JC), Jayachandran, David S. Miller, Andrew Lunn,
Chintan Vankar, Danish Anwar, Daolin Qiu, Eric Dumazet,
Felix Maurer, Jakub Kicinski, Paolo Abeni, Richard Cochran,
Simon Horman, Raghavendra, Vignesh, Bajjuri, Praneeth,
TK, Pratheesh Gangadhar, Muralidharan, Neelima
In-Reply-To: <20260416161856.CsL4npMH@linutronix.de>
Sebastian Andrzej Siewior wrote:
> On 2026-04-06 10:47:56 [-0400], Willem de Bruijn wrote:
> Hi Willem,
>
> > So the requirement is for a communication path between userspace and
> > the driver over packet sockets.
> >
> > Existing options that work for both rx and tx are
> >
> > - in-band: a packet header or footer
> > - mark, metadata
> > - maybe: vlan tags
> >
> > These require changes in the HSR driver to use them, but no changes in
> > the protocol independent core logic, which includes packet sockets.
> >
> > As I mentioned before we cannot sprinkle protocol specific code
> > throughout protocol independent core code. That quickly leads to an
> > unmaintainable mess. PTP over HSR is a particular small niche case,
> > nowhere near first in line to get an exception to this guideline.
>
> I understand your concern. I tried to make as self contained as
> possible and little runtime overhead as possible.
>
> > One perhaps interesting Rx only option I had missed before is
> > SOF_TIMESTAMPING_OPT_PKTINFO. Would that give you the original
> > device ifindex today?
>
> The upper logic expects to poll() on the fd. If I need to filter the
> device based on this then breaks the expectations.
> I need also to receive packets without a timestamp so I don't think this
> works.
I don't follow this. My suggestion is to optionally receive this
additional metadata along with the data. Not as a filter.
> > If so, we now only have to consider the Tx path to the HSR driver
> > (the Tx path directly to the other drivers do not need this metadata).
> >
> > I'm not convinced that it is hard to come up with a way to send
> > a packet to the HSR driver with an optional header or footer or
> > vlan data (or skb->protocol perhaps?) that cannot be
> > differentiated from other traffic arriving at that ndo_start_xmit.
>
> I've been looking to skb->protocol. Maybe if the packet has ether type
> set to PTP then the HSR layer could consider everything before it (the
> two MAC address fields) as internal header and the actual packet starts
> after that. Reasoning would be that you shouldn't send a PTP packet over
> HSR without dealing with the restrictions. So this could work.
>
> Then the question remains how to do the filtering on RX side. For the
> so_mark I did open additional two sockets…
>
> > If all this fails, we can look into a protocol independent approach
> > to passing other metadata in packet sockets. to/from skb_ext or cb[],
> > say.
>
> I will try the above but it looks very hackish.
> cb[] is limited to one layer. I do have a skb_ext variant working but
> this requires cmsg to set it. Do you think about generic skb_ext which
> is set from af_packet? But I don't think it brings much value if I can't
> filter on the RX side before returning the packet to userland.
>
> > But at this point I see enough options that do not require changes
> > to packet sockets.
> >
> > To get back to the simplest approach: skb->mark. Is there any
> > concrete risk that on this path that would conflict with other
> > uses of that field? If packet sockets inject directly into this
> > driver (possibly even with PACKET_QDISC_BYPASS)?
>
> So I have a skb->mark variant working. I do read on the ethX interface
When reading on both ethX interfaces, that gives you all the info you
need on Rx, right? Or alternatively by attaching to hsr0 with
SOF_TIMESTAMPING_OPT_PKTINFO.
So skb->mark is only relevant to the Tx side, right? There might be
yet another way to identify in the hsr ndo_start_xmit that a packet
arrived from a PF_PACKET socket. E.g., by checking skb->sk->sk_family.
As alternative or complement to skb->protocol.
Btw, on receive the inverse could also be true: insert a synthetic
header and pop that in userspace, e.g., a VLAN tag.
> and write on the hsr0 interface (so I need two extra fd per interface).
> The only concern here is that the mark value is hardcoded and could
> collide with an existing firewall setup or so.
> This field needs also be evaluated by the ethernet driver in case of
> hw-offloading for HSR.
> So far, this is the only working solution I have which does not touch
> af_packet.
>
> Let me try the header with the PTP hedaer type and the additional
> sockets for RX.
> It will not win a beauty contest but maybe I judge too harsh…
>
> Sebastian
^ permalink raw reply
* Re: [PATCH net] ipv6: rpl: expand skb head when recompressed SRH grows, not only on last segment
From: Greg KH @ 2026-04-21 7:48 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: davem, dsahern, edumazet, horms, kuba, linux-kernel, netdev,
pabeni, stable
In-Reply-To: <2026042140-drench-pursuable-37fa@gregkh>
On Tue, Apr 21, 2026 at 07:50:45AM +0200, Greg KH wrote:
> On Tue, Apr 21, 2026 at 04:52:52AM +0000, Kuniyuki Iwashima wrote:
> > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Date: Mon, 20 Apr 2026 21:32:25 +0200
> > > ipv6_rpl_srh_rcv() processes a Routing Protocol for LLNs Source Routing
> > > Header by decompressing it, swapping the next segment address into
> > > ipv6_hdr->daddr, recompressing, and pushing the new header back. The
> > > recompressed header can be larger than the original when the
> > > address-elision opportunities are worse after the swap.
> > >
> > > The function pulls (hdr->hdrlen + 1) << 3 bytes (the old header) and
> > > pushes (chdr->hdrlen + 1) << 3 + sizeof(ipv6hdr) bytes (the new header
> > > plus the IPv6 header). pskb_expand_head() is called to guarantee
> > > headroom only when segments_left == 0.
> > >
> > > A crafted SRH that loops back to the local host (each segment is a local
> > > address, so ip6_route_input() delivers it back to ipv6_rpl_srh_rcv())
> > > with chdr growing on each pass exhausts headroom over several
> > > iterations.
> >
> > How could this occur.. ? Did AI generate a repro or just
> > flagged the possibility ?
>
> It generated a reproducer which caused a crash which made me have to
> create this patch. I'll dig it out of the huge pile of mess that was
> sent to me and get it into a form that I can reply here to.
Ok, got the reproducer working, and it turns out that this patch does
NOT fix the issue, I should have tested it better. Let me work some
more on this thing, sorry for the broken submission.
thanks,
greg k-h
^ permalink raw reply
* [PATCH net v2] ipv6: addrconf: skip ERRDAD transition when address already DEAD
From: Linmao Li @ 2026-04-21 7:50 UTC (permalink / raw)
To: davem, dsahern, edumazet, kuba, pabeni
Cc: horms, netdev, linux-kernel, Linmao Li
In-Reply-To: <20260420032842.1063277-1-lilinmao@kylinos.cn>
addrconf_dad_end() transitions ifp->state from DAD to POSTDAD under
ifp->lock and releases the lock. addrconf_dad_failure() takes
ifp->lock again with the spin_lock_bh() following the
net_info_ratelimited() duplicate-address log. A concurrent
ipv6_del_addr() can acquire the lock in that window, set ifp->state
to DEAD and run list_del_rcu(&ifp->if_list).
addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad:
and schedules a new dad_work. The work calls ipv6_del_addr() again,
hitting the already-poisoned list entry:
general protection fault: 0000 [#1] SMP NOPTI
CPU: 4 PID: 217 Comm: kworker/4:1
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:ipv6_del_addr+0xe9/0x280
RAX: dead000000000122
Call Trace:
addrconf_dad_stop+0x113/0x140
addrconf_dad_work+0x28c/0x430
process_one_work+0x1eb/0x3b0
worker_thread+0x4d/0x400
kthread+0x104/0x140
ret_from_fork+0x35/0x40
Bail out at errdad: when ifp->state is already DEAD. The existing
in6_ifa_put() releases the reference taken for this invocation.
Fixes: c15b1ccadb32 ("ipv6: move DAD and addrconf_verify processing to workqueue")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
---
net/ipv6/addrconf.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 5476b6536eb7..14b1ab43da87 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2227,6 +2227,12 @@ void addrconf_dad_failure(struct sk_buff *skb, struct inet6_ifaddr *ifp)
errdad:
/* transition from _POSTDAD to _ERRDAD */
+ if (ifp->state == INET6_IFADDR_STATE_DEAD) {
+ /* ipv6_del_addr() already removed ifp while lock was dropped */
+ spin_unlock_bh(&ifp->lock);
+ in6_ifa_put(ifp);
+ return;
+ }
ifp->state = INET6_IFADDR_STATE_ERRDAD;
spin_unlock_bh(&ifp->lock);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] ieee802154: ca8210: fix cas_ctl leak on spi_async failure
From: Miquel Raynal @ 2026-04-21 7:52 UTC (permalink / raw)
To: Shitalkumar Gandhi
Cc: alex.aring, stefan, andrew+netdev, davem, edumazet, kuba, pabeni,
linux-wpan, netdev, linux-kernel, stable, Shitalkumar Gandhi
In-Reply-To: <20260421073259.2259783-1-shitalkumar.gandhi@cambiumnetworks.com>
Hello,
On 21/04/2026 at 13:02:59 +0530, Shitalkumar Gandhi <shital.gandhi45@gmail.com> wrote:
> ca8210_spi_transfer() allocates cas_ctl with kzalloc_obj(GFP_ATOMIC)
> and relies entirely on the SPI completion callback
> ca8210_spi_transfer_complete() to free it.
[...]
> Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com>
> ---
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Thanks,
Miquèl
^ permalink raw reply
* Re: [PATCH net v2] slip: reject VJ receive packets on instances with no rstate array
From: patchwork-bot+netdevbpf @ 2026-04-21 8:00 UTC (permalink / raw)
To: Weiming Shi; +Cc: andrew+netdev, davem, edumazet, kuba, pabeni, netdev, xmei5
In-Reply-To: <20260415204130.258866-2-bestswngs@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Thu, 16 Apr 2026 04:41:31 +0800 you wrote:
> slhc_init() accepts rslots == 0 as a valid configuration, with the
> documented meaning of 'no receive compression'. In that case the
> allocation loop in slhc_init() is skipped, so comp->rstate stays
> NULL and comp->rslot_limit stays 0 (from the kzalloc of struct
> slcompress).
>
> The receive helpers do not defend against that configuration.
> slhc_uncompress() dereferences comp->rstate[x] when the VJ header
> carries an explicit connection ID, and slhc_remember() later assigns
> cs = &comp->rstate[...] after only comparing the packet's slot number
> to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the
> range check, and the code dereferences a NULL rstate.
>
> [...]
Here is the summary with links:
- [net,v2] slip: reject VJ receive packets on instances with no rstate array
https://git.kernel.org/netdev/net/c/e76607442d5b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v5 net] nfc: hci: fix out-of-bounds read in HCP header parsing
From: Paolo Abeni @ 2026-04-21 8:06 UTC (permalink / raw)
To: Simon Horman, Ashutosh Desai
Cc: netdev, kuba, edumazet, davem, stable, linux-kernel
In-Reply-To: <20260418163024.GH280379@horms.kernel.org>
On 4/18/26 6:30 PM, Simon Horman wrote:
> On Thu, Apr 16, 2026 at 05:15:22AM +0000, Ashutosh Desai wrote:
>> nfc_hci_recv_from_llc() and nci_hci_data_received_cb() cast skb->data
>> to struct hcp_packet and read the message header byte without checking
>> that enough data is present in the linear sk_buff area. A malicious NFC
>> peer can send a 1-byte HCP frame that passes through the SHDLC layer
>> and reaches these functions, causing an out-of-bounds heap read.
>>
>> Fix this by adding pskb_may_pull() before each cast to ensure the full
>> 2-byte HCP header is pulled into the linear area before it is accessed.
>>
>> Fixes: 8b8d2e08bf0d ("NFC: HCI support")
>> Fixes: 11f54f228643 ("NFC: nci: Add HCI over NCI protocol support")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com>
>> ---
>> V4 -> V5: fix whitespace damage
>> V3 -> V4: add Fixes tags
>> V2 -> V3: drop redundant checks from nfc_hci_msg_rx_work/nci_hci_msg_rx_work;
>> remove incorrect Suggested-by tag
>> V1 -> V2: use pskb_may_pull() instead of skb->len check
>>
>> v4: https://lore.kernel.org/netdev/177614425081.3600288.2536320552978506086@gmail.com/
>> v3: https://lore.kernel.org/netdev/20260413024329.3293075-1-ashutoshdesai993@gmail.com/
>> v2: https://lore.kernel.org/netdev/20260409150825.2217133-1-ashutoshdesai993@gmail.com/
>> v1: https://lore.kernel.org/netdev/20260408223113.2009304-1-ashutoshdesai993@gmail.com/
>>
>> net/nfc/hci/core.c | 5 +++++
>> net/nfc/nci/hci.c | 5 +++++
>> 2 files changed, 10 insertions(+)
>
> Reviewed-by: Simon Horman <horms@kernel.org>
>
> Review of this patch at Sashiko.dev flags a number of related problems in
> this code. I believe none of them introduced by this patch. And that
> they can all be treated as area for possible follow-up.
I agree that the issue reported by sashiko:
---
Does this patch fully resolve the out-of-bounds access?
Looking at the beginning of nfc_hci_recv_from_llc(), the code accesses
the packet header before checking if the skb has any data:
net/nfc/hci/core.c:nfc_hci_recv_from_llc() {
packet = (struct hcp_packet *)skb->data;
if ((packet->header & ~NFC_HCI_FRAGMENT) == 0) {
skb_queue_tail(&hdev->rx_hcp_frags, skb);
return;
}
...
}
If a maliciously crafted 0-byte payload is received, couldn't this
result in an out-of-bounds read of uninitialized memory?
Furthermore, if the fragmentation bit is clear and this 0-byte skb
is queued, when a subsequent final fragment arrives, the reassembly
loop calculates the message length:
net/nfc/hci/core.c:nfc_hci_recv_from_llc() {
...
skb_queue_walk(&hdev->rx_hcp_frags, frag_skb) {
msg_len += (frag_skb->len - NFC_HCI_HCP_PACKET_HEADER_LEN);
}
...
}
Since NFC_HCI_HCP_PACKET_HEADER_LEN is 1, wouldn't a 0-length fragment
cause this calculation to underflow to UINT_MAX, leading to an eventual
skb_over_panic() when skb_put_data() is called?
Would it be safer to add a pskb_may_pull(skb, 1) check at the very start
of the function before packet->header is accessed?
---
is pre-existing but it looks like the validation included here is almost
ineffective without addressing the above.
@Ashutosh, please include the additional validation in the next
revision, thanks!
Paolo
^ permalink raw reply
* Re: [PATCH net] netdevsim: Initialize all fields of ip header when building dummy sk_buff
From: Breno Leitao @ 2026-04-21 8:19 UTC (permalink / raw)
To: Nikola Z. Ivanov
Cc: kuba, andrew+netdev, davem, edumazet, pabeni, netdev,
linux-kernel
In-Reply-To: <20260421073738.22110-1-zlatistiv@gmail.com>
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
^ permalink raw reply
* Re: [PATCH v4] net: wwan: t7xx: validate port_count against message length in t7xx_port_enum_msg_handler
From: Paolo Abeni @ 2026-04-21 8:25 UTC (permalink / raw)
To: Pavitra Jha, w; +Cc: chandrashekar.devegowda, linux-wwan, netdev, stable
In-Reply-To: <20260416113205.1789319-1-jhapavitra98@gmail.com>
On 4/16/26 1:32 PM, Pavitra Jha wrote:
> t7xx_port_enum_msg_handler() uses the modem-supplied port_count field as
> a loop bound over port_msg->data[] without checking that the message buffer
> contains sufficient data. A modem sending port_count=65535 in a 12-byte
> buffer triggers a slab-out-of-bounds read of up to 262140 bytes.
>
> Add a struct_size() check after extracting port_count and before the loop.
> Pass msg_len to t7xx_port_enum_msg_handler() and use it to validate
> the message size before accessing port_msg->data[].
> Pass msg_len from both call sites: skb->len at the DPMAIF path after
> skb_pull(), and the captured rt_feature->data_len at the handshake path.
>
> Fixes: 39d439047f1d ("net: wwan: t7xx: Add control DMA interface")
> Cc: stable@vger.kernel.org
> Signed-off-by: Pavitra Jha <jhapavitra98@gmail.com>
Does not apply cleanly to net, patch says:
patching file drivers/net/wwan/t7xx/t7xx_modem_ops.c
patch: **** malformed patch at line 41: return 0;
are you using any https://xkcd.com/378/ derived method to cook your
path? please stick to old good git and verify your local configuration.
/P
^ permalink raw reply
* Re: [PATCH net] slip: bound decode() reads against the compressed packet length
From: patchwork-bot+netdevbpf @ 2026-04-21 8:30 UTC (permalink / raw)
To: Weiming Shi; +Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms, netdev
In-Reply-To: <20260416100147.531855-5-bestswngs@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Thu, 16 Apr 2026 18:01:51 +0800 you wrote:
> slhc_uncompress() parses a VJ-compressed TCP header by advancing a
> pointer through the packet via decode() and pull16(). Neither helper
> bounds-checks against isize, and decode() masks its return with
> & 0xffff so it can never return the -1 that callers test for -- those
> error paths are dead code.
>
> A short compressed frame whose change byte requests optional fields
> lets decode() read past the end of the packet. The over-read bytes
> are folded into the cached cstate and reflected into subsequent
> reconstructed packets.
>
> [...]
Here is the summary with links:
- [net] slip: bound decode() reads against the compressed packet length
https://git.kernel.org/netdev/net/c/4c1367a2d7aa
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 03/23] tick/nohz: Make nohz_full parameter optional
From: Thomas Gleixner @ 2026-04-21 8:32 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-4-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> To provide nohz_full tick support, there is a set of tick dependency
> masks that need to be evaluated on every IRQ and context switch.
s/IRQ/interrupt/
This is a changelog and not a SMS service.
> Switching on nohz_full tick support at runtime will be problematic
> as some of the tick dependency masks may not be properly set causing
> problem down the road.
That's useless blurb with zero content.
> Allow nohz_full boot option to be specified without any
> parameter to force enable nohz_full tick support without any
> CPU in the tick_nohz_full_mask yet. The context_tracking_key and
> tick_nohz_full_running flag will be enabled in this case to make
> tick_nohz_full_enabled() return true.
I kinda can crystal-ball what you are trying to say here, but that does
not make it qualified as a proper change log.
> There is still a small performance overhead by force enable nohz_full
> this way. So it should only be used if there is a chance that some
> CPUs may become isolated later via the cpuset isolated partition
> functionality and better CPU isolation closed to nohz_full is desired.
Why has this key to be enabled on boot if there are no CPUs in the
isolated mask?
If you want to manage this dynamically at runtime then enable the key
once CPUs are isolated. Yes, it's more work, but that avoids the "should
only be used" nonsense and makes this more robust down the road.
Thanks,
tglx
^ permalink raw reply
* 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
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