* Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Fidelio LAWSON @ 2026-04-14 13:48 UTC (permalink / raw)
To: Andrew Lunn, Marek Vasut
Cc: Woojung Huh, UNGLinuxDriver, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Marek Vasut,
Maxime Chevallier, Simon Horman, Heiner Kallweit, Russell King,
netdev, linux-kernel, Fidelio Lawson
In-Reply-To: <d9b161dd-f698-4d7e-8ccb-9ec12411bf87@lunn.ch>
On 4/14/26 14:40, Andrew Lunn wrote:
> On Tue, Apr 14, 2026 at 01:05:49PM +0200, Marek Vasut wrote:
>> On 4/14/26 11:12 AM, Fidelio Lawson wrote:
>>> Implement the "Module 3: Equalizer fix for short cables" erratum from
>>> Microchip document DS80000687C for KSZ87xx switches.
>>>
>>> The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
>>> where the PHY receiver equalizer may amplify high-amplitude signals
>>> excessively, resulting in internal distortion and link establishment
>>> failures.
>>>
>>> KSZ87xx devices require a workaround for the Module 3 low-loss cable
>>> condition, controlled through the switch TABLE_LINK_MD_V indirect
>>> registers.
>>>
>>> The affected registers are part of the switch address space and are not
>>> directly accessible from the PHY driver. To keep the PHY-facing API
>>> clean and avoid leaking switch-specific details, model this errata
>>> control as vendor-specific Clause 22 PHY registers.
>>>
>>> A vendor-specific Clause 22 PHY register is introduced as a mode
>>> selector in PHY_REG_LOW_LOSS_CTRL, and ksz8_r_phy() / ksz8_w_phy()
>>> translate accesses to these bits into the appropriate indirect
>>> TABLE_LINK_MD_V accesses.
>>>
>>> The control register defines the following modes:
>>> 0: disabled (default behavior)
>>> 1: EQ training workaround
>>> 2: LPF 90 MHz
>>> 3: LPF 62 MHz
>>> 4: LPF 55 MHz
>>> 5: LPF 44 MHz
>> I may not fully understand this, but aren't the EQ and LPF settings
>> orthogonal ?
>
> What is the real life experience using this feature? Is it needed for
> 1cm cables, but most > 1m cables are O.K with the defaults? Do we need
> all these configuration options? How is a user supposed to discover
> the different options? Can we simplify it down to a Boolean?
>
> Ethernet is just supposed to work with any valid length of cable,
> KISS. So maybe we should try to keep this feature KISS. Just tell the
> driver it is a short cable, pick different defaults which should work
> with any short cable?
>
> A boolean should also help with making this tunable reusable with
> other devices. It is unlikely any other devices have these same
> configuration options, unless it is from the same vendor.
>
> Andrew
The issue has been observed with very short or low‑loss
cables, typically in industrial or embedded setups where the cable is
below 3m or in a board-to-board setup.
From our practical experience, this issue occurs in our setup where a
very short CAT‑6e cable (~20cm) is used.
We were seeing random link dropouts with the default settings, and since
enabling the workaround 2, the link has remained stable and we have not
observed any further issues.
We don’t need all these configuration options.
According to the Microchip erratum, the user should try workaround 1 (EQ
training), and if that does not resolve the random link dropouts,
fall back to workaround 2 by reducing the LPF bandwidth to 62MHz.
Since this procedure for determining which workaround is effective is
inherently experimental and requires observation in real deployments,
this is why I originally chose to expose the selection of the workaround
to the user, at least allowing them to choose between workaround 1 and
workaround 2.
regards
Fidelio
^ permalink raw reply
* Re: [PATCH net] slip: reject VJ frames when no receive slots are allocated
From: Simon Horman @ 2026-04-14 13:41 UTC (permalink / raw)
To: bestswngs
Cc: 'Simon Horman', andrew+netdev, davem, edumazet, kuba,
pabeni, kees, netdev, xmei5
In-Reply-To: <20260412154252.2060940-2-bestswngs@gmail.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
slip: reject VJ frames when no receive slots are allocated
This commit prevents a null pointer dereference by adding checks for
a NULL comp->rstate in slhc_uncompress() and slhc_remember(). It ensures
frames are rejected when no receive slots are allocated.
> diff --git a/drivers/net/slip/slhc.c b/drivers/net/slip/slhc.c
> index e3c785da3eef3..e67052bcab57b 100644
> --- a/drivers/net/slip/slhc.c
> +++ b/drivers/net/slip/slhc.c
> @@ -502,6 +502,10 @@ slhc_uncompress(struct slcompress *comp, unsigned char *icp, int isize)
>
> /* We've got a compressed packet; read the change byte */
> comp->sls_i_compressed++;
> + if (!comp->rstate) {
> + comp->sls_i_error++;
> + return 0;
> + }
While reviewing this code, a few pre-existing issues were noticed in and
around slhc_uncompress().
Can slhc_uncompress() cause a heap buffer overflow?
It expands compressed packets by prepending reconstructed IP and TCP
headers, which can total up to 120 bytes if options are maximized. The
caller in slip.c assumes a maximum expansion of 80 bytes:
if (count + 80 > sl->buffsize)
If a compressed packet is sized at sl->buffsize - 80, slhc_uncompress()
shifts the payload and copies the 120-byte headers, writing up to 37 bytes
past the dynamically allocated sl->rbuff chunk. Does this corrupt memory?
Also, does the decode() function read variable-length deltas without
bounds checking against the packet length isize?
A malformed packet with multiple change flags set could cause decode()
to read up to 15 bytes past the end of the packet data. Because the packet
buffer sl->rbuff is allocated via kmalloc without zero-initialization,
could this read uninitialized kernel heap memory and inject it into the
reconstructed TCP/IP headers, leaking it back to the network?
Finally, do slhc_compress() and slhc_uncompress() read and write the
16-bit TCP checksum using direct pointer casts?
drivers/net/slip/slhc.c:slhc_uncompress() {
...
thp->check = *(__sum16 *)cp;
...
}
Since the compressed header varies dynamically in size, the cp pointer
frequently lands on odd byte boundaries. On architectures with strict
alignment requirements, could this direct dereference trigger an alignment
fault and kernel panic? Should the code use get_unaligned() and
put_unaligned() instead?
[ ... ]
> @@ -651,8 +655,9 @@ slhc_remember(struct slcompress *comp, unsigned char *icp, int isize)
>
> /* The packet is shorter than a legal IP header.
> * Also make sure isize is positive.
> + * Reject if no receive slots are configured (rstate is NULL).
> */
> - if (isize < (int)sizeof(struct iphdr)) {
> + if (!comp->rstate || isize < (int)sizeof(struct iphdr)) {
> runt:
> comp->sls_i_runt++;
> return slhc_toss(comp);
When dropping a packet due to a lack of configured receive slots
(rslots == 0), should this increment comp->sls_i_error instead of
comp->sls_i_runt?
Dropping a packet because rstate is missing is an internal configuration
state, not a runt packet.
^ permalink raw reply
* Re: [PATCH RFC bpf-next 8/8] selftests/bpf: add tests to validate KASAN on JIT programs
From: Alexis Lothoré @ 2026-04-14 13:43 UTC (permalink / raw)
To: Andrey Konovalov, Alexis Lothoré (eBPF Foundation)
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
David S. Miller, David Ahern, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, linux-kernel, netdev, linux-kselftest,
linux-stm32, linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CA+fCnZekgcEgsZnRrOB=+HoG=neRg=oLTt2jStyrPJ6mYf2ctQ@mail.gmail.com>
On Tue Apr 14, 2026 at 12:20 AM CEST, Andrey Konovalov wrote:
> On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation)
> <alexis.lothore@bootlin.com> wrote:
>>
>> Add a basic KASAN test runner that loads and test-run programs that can
>> trigger memory management bugs. The test captures kernel logs and ensure
>> that the expected KASAN splat is emitted by searching for the
>> corresponding first lines in the report.
>>
>> This version implements two faulty programs triggering either a
>> user-after-free, or an out-of-bounds memory usage. The bugs are
>> triggered thanks to some dedicated kfuncs in bpf_testmod.c, but two
>> different techniques are used, as some cases can be quite hard to
>> trigger in a pure "black box" approach:
>> - for reads, we can make the used kfuncs return some faulty pointers
>> that ebpf programs will manipulate, they will generate legitimate
>> kasan reports as a consequence
>> - applying the same trick for faulty writes is harder, as ebpf programs
>> can't write kernel data freely. So ebpf programs can call another
>> specific testing kfunc that will alter the shadow memory matching the
>> passed memory (eg: a map). When the program will try to write to the
>> corresponding memory, it will trigger a report as well.
>>
>> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
>> ---
>> The way of bringing kasan_poison into bpf_testmod is definitely not
>> ideal. But I would like to validate the testing approach (triggering
>> real faulty accesses, which is hard on some cases, VS manually poisoning
>> BPF-manipulated memory) before eventually making clean bridges between
>> KASAN APIs and bpf_testmod.c, if the latter approach is the valid one.
>
> Would it make sense to put these tests into KASAN KUnit tests in
> mm/kasan/kasan_test_c.c? I assume there is a kernel API to JIT BPF
> programs from the kernel itself?
Possibly indeed, but I think one important use case will be the
possibility to run those tests in BPF CI ([1]), and this depends on
those tests being integrated in the test_progs framework
(tools/testing/selftests/bpf)
[1] https://github.com/kernel-patches/bpf/pulls
> There, you can just call kasan_poison(), some tests already do this.
> And you can also extend the KASAN KUnit test framework to find out
> whether the bad access is a read or write, if you want to check this.
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH iwl-next v2 7/8] ixgbe: use GFP_KERNEL in ixgbe_fcoe_ddp_setup()
From: Simon Horman @ 2026-04-14 13:29 UTC (permalink / raw)
To: aleksandr.loktionov
Cc: Simon Horman, anthony.l.nguyen, marcin.szycik, intel-wired-lan,
jacob.e.keller, netdev
In-Reply-To: <20260408131216.2662245-8-aleksandr.loktionov@intel.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
ixgbe: use GFP_KERNEL in ixgbe_fcoe_ddp_setup()
This commit restructures ixgbe_fcoe_ddp_setup() to use GFP_KERNEL
instead of GFP_ATOMIC by splitting get_cpu()/put_cpu() usage into two
narrow critical sections, moving DMA mapping and pool allocation between
them where preemption is enabled.
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> index 011fda9c6193..e338ff0e6522 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
[ ... ]
> @@ -179,29 +180,43 @@ static int ixgbe_fcoe_ddp_setup(struct net_device *netdev, u16 xid,
> return 0;
> }
>
> + /* Pin to current CPU only to read the per-CPU pool pointer; drop
> + * the pin before any allocations that may sleep under direct reclaim.
> + */
> ddp_pool = per_cpu_ptr(fcoe->ddp_pool, get_cpu());
> if (!ddp_pool->pool) {
> e_warn(drv, "xid=0x%x no ddp pool for fcoe\n", xid);
> - goto out_noddp;
> + put_cpu();
> + return 0;
> }
> + pool = ddp_pool->pool;
> + put_cpu();
>
> /* setup dma from scsi command sgl */
> dmacount = dma_map_sg(&adapter->pdev->dev, sgl, sgc, DMA_FROM_DEVICE);
> if (dmacount == 0) {
> e_err(drv, "xid 0x%x DMA map error\n", xid);
> - goto out_noddp;
> + return 0;
> }
>
> - /* alloc the udl from per cpu ddp pool */
> - ddp->udl = dma_pool_alloc(ddp_pool->pool, GFP_ATOMIC, &ddp->udp);
> + /* Allocate from per-CPU pool; GFP_KERNEL is safe: preemption is
> + * re-enabled after the put_cpu() above. Per-CPU DMA pools are only
> + * destroyed under RTNL during interface teardown, so the saved pool
> + * pointer remains valid.
> + */
> + ddp->udl = dma_pool_alloc(pool, GFP_KERNEL, &ddp->udp);
Is this safe given the calling context?
Looking at the call path from the FCoE stack:
fc_exch_seq_send()
fc_exch_alloc()
fc_exch_em_alloc()
spin_lock_bh(&pool->lock)
# allocate exchange
# set ep->ex_lock = held
return with ep->ex_lock still held
fc_fcp_ddp_setup()
lport->tt.ddp_setup()
.ndo_fcoe_ddp_setup() == ixgbe_fcoe_ddp_get()
ixgbe_fcoe_ddp_setup() # <-- we are here
# ... continues with ep->ex_lock held
spin_unlock_bh(&ep->ex_lock)
fc_exch_em_alloc() acquires ep->ex_lock (a spinlock) and returns with
it held. The lock remains held through fc_fcp_ddp_setup() and into
ixgbe_fcoe_ddp_setup(). Additionally, spin_lock_bh() disables bottom
halves.
Can GFP_KERNEL be used while holding ep->ex_lock with BH disabled, or
does this require GFP_ATOMIC?
^ permalink raw reply
* Re: [PATCH v2] wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exit
From: Jason A. Donenfeld @ 2026-04-14 13:28 UTC (permalink / raw)
To: Shardul Bankar
Cc: kuniyu, andrew+netdev, davem, edumazet, kuba, pabeni, wireguard,
netdev, linux-kernel, janak, kalpan.jani, shardulsb08,
syzbot+f2fbf7478a35a94c8b7c
In-Reply-To: <20260413151232.1004611-1-shardul.b@mpiricsoftware.com>
Hi Shardul,
On Mon, Apr 13, 2026 at 5:13 PM Shardul Bankar
<shardul.b@mpiricsoftware.com> wrote:
>
> wg_netns_pre_exit() manually acquires rtnl_lock() inside the
> pernet .pre_exit callback. This causes a hung task when another
> thread holds rtnl_mutex - the cleanup_net workqueue (or the
> setup_net failure rollback path) blocks indefinitely in
> wg_netns_pre_exit() waiting to acquire the lock.
>
> Convert to .exit_rtnl, introduced in commit 7a60d91c690b ("net:
> Add ->exit_rtnl() hook to struct pernet_operations."), where the
> framework already holds RTNL and batches all callbacks under a
> single rtnl_lock()/rtnl_unlock() pair, eliminating the contention
> window.
>
> The rcu_assign_pointer(wg->creating_net, NULL) is safe to move
> from .pre_exit to .exit_rtnl (which runs after synchronize_rcu())
> because all RCU readers of creating_net either use maybe_get_net()
> - which returns NULL for a dying namespace with zero refcount - or
> access net->user_ns which remains valid throughout the entire
> ops_undo_list sequence.
>
> Reported-by: syzbot+f2fbf7478a35a94c8b7c@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?id=cb64c22a492202ca929e18262fdb8cb89e635c70
> Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
Thanks. Applied to the wireguard tree, and also added the missing
__net_exit and __read_mostly annotations in the process.
Jason
^ permalink raw reply
* Re: [PATCH RFC bpf-next 3/8] bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs
From: Alexis Lothoré @ 2026-04-14 13:24 UTC (permalink / raw)
To: Andrey Konovalov, Alexis Lothoré (eBPF Foundation)
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
David S. Miller, David Ahern, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, linux-kernel, netdev, linux-kselftest,
linux-stm32, linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CA+fCnZf-o8tiv_tX9YB5eBUGx17OpztKZsEB6Awjw3WAqBAiUw@mail.gmail.com>
On Tue Apr 14, 2026 at 12:20 AM CEST, Andrey Konovalov wrote:
> On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation)
> <alexis.lothore@bootlin.com> wrote:
>>
>> Add a new Kconfig option CONFIG_BPF_JIT_KASAN that automatically enables
>> KASAN (Kernel Address Sanitizer) memory access checks for JIT-compiled
>> BPF programs, when both KASAN and JIT compiler are enabled. When
>> enabled, the JIT compiler will emit shadow memory checks before memory
>> loads and stores to detect use-after-free, out-of-bounds, and other
>> memory safety bugs at runtime. The option is gated behind
>> HAVE_EBPF_JIT_KASAN, as it needs proper arch-specific implementation.
>>
>> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
>> ---
>> kernel/bpf/Kconfig | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
>> index eb3de35734f0..28392adb3d7e 100644
>> --- a/kernel/bpf/Kconfig
>> +++ b/kernel/bpf/Kconfig
>> @@ -17,6 +17,10 @@ config HAVE_CBPF_JIT
>> config HAVE_EBPF_JIT
>> bool
>>
>> +# KASAN support for JIT compiler
>> +config HAVE_EBPF_JIT_KASAN
>> + bool
>> +
>> # Used by archs to tell that they want the BPF JIT compiler enabled by
>> # default for kernels that were compiled with BPF JIT support.
>> config ARCH_WANT_DEFAULT_BPF_JIT
>> @@ -101,4 +105,9 @@ config BPF_LSM
>>
>> If you are unsure how to answer this question, answer N.
>>
>> +config BPF_JIT_KASAN
>> + bool
>> + depends on HAVE_EBPF_JIT_KASAN
>> + default y if BPF_JIT && KASAN_GENERIC
>
> Should this be "depends on KASAN && KASAN_GENERIC"?
Meaning, making it an explicit user-selectable option ?
If so, the current design choice is voluntary and based on the feedback
received on the original RFC, where I have been suggested to
automatically enable the KASAN instrumentation in BPF programs if KASAN
support is enabled in the kernel ([1]). But if a user-selectable toggle
is eventually a better solution, I'm fine with changing it.
[1] https://lore.kernel.org/bpf/CAADnVQLX7RSnOqQuU32Cgq-e0MVqyeNrtCQSBbk0W2xGkE-ZNw@mail.gmail.com/
>
>
>> +
>> endmenu # "BPF subsystem"
>>
>> --
>> 2.53.0
>>
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH iwl-next v2 5/8] ixgbe: remove ixgbe_ping_all_vfs() from link state change handlers
From: Simon Horman @ 2026-04-14 13:23 UTC (permalink / raw)
To: aleksandr.loktionov
Cc: 'Simon Horman', intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260408131216.2662245-6-aleksandr.loktionov@intel.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
ixgbe: remove ixgbe_ping_all_vfs() from link state change handlers
This commit removes ixgbe_ping_all_vfs() from the link watchdog handlers
to prevent a race condition during VF initialization where a gratuitous
ping collides with the VF mailbox state machine.
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 8110bcf006a30..3071302901499 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -8164,9 +8164,6 @@ static void ixgbe_watchdog_link_is_up(struct ixgbe_adapter *adapter)
>
> /* update the default user priority for VFs */
> ixgbe_update_default_up(adapter);
> -
> - /* ping all the active vfs to let them know link has changed */
> - ixgbe_ping_all_vfs(adapter);
> }
How will legacy VFs (such as 82599, X540, and X550) receive link state
changes without these pings?
The commit message states that link-state changes are already communicated
to VFs through the normal mailbox protocol. However, older VFs appear to
rely on receiving an IXGBE_VT_MSGTYPE_CTS message from the PF to clear
mac->get_link_status and complete the link up sequence in
ixgbevf_check_mac_link_vf().
Without the ping, will these legacy VFs fail to read the mailbox and stay
stuck reporting the link as down?
Is the mailbox corruption race still triggerable from other paths?
If ixgbe_ping_vf() is called locklessly from process-context NDO callbacks
like ixgbe_ndo_set_vf_link_state() or ixgbe_ndo_set_vf_trust(), could it be
preempted by a hardirq triggering ixgbe_msg_task() (which correctly acquires
vfs_lock before writing to the mailbox)?
Since ixgbe_write_mbx_pf() only arbitrates between the PF and VF via the
IXGBE_PFMAILBOX_PFU hardware lock, it provides no mutual exclusion between
concurrent host threads. Could concurrent writes corrupt the IXGBE_PFMBMEM
buffer and cause the exact same VF initialization failure this patch intended
to fix?
Would wrapping the pings in spin_lock_irqsave(&adapter->vfs_lock, flags)
prevent the mailbox corruption instead of removing the pings entirely?
[ ... ]
> @@ -8197,9 +8194,6 @@ static void ixgbe_watchdog_link_is_down(struct ixgbe_adapter *adapter)
>
> e_info(drv, "NIC Link is Down\n");
> netif_carrier_off(netdev);
> -
> - /* ping all the active vfs to let them know link has changed */
> - ixgbe_ping_all_vfs(adapter);
> }
Without this ping, will older VFs miss the mailbox interrupt needed to set
mac->get_link_status = 1, causing them to remain stuck reporting the link as
up indefinitely and silently drop traffic when the cable is unplugged?
This isn't a bug, but removing the calls from the link handlers appears to
leave ixgbe_ping_all_vfs() as dead code without any remaining callers in
the kernel. Should the function definition in ixgbe_sriov.c and its
declaration in ixgbe_sriov.h be removed as well?
^ permalink raw reply
* Re: [PATCH net] net: airoha: Add missing PPE configurations in airoha_ppe_hw_init()
From: patchwork-bot+netdevbpf @ 2026-04-14 13:20 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260412-airoha_ppe_hw_init-missing-bits-v1-1-06ac670819e3@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sun, 12 Apr 2026 10:43:26 +0200 you wrote:
> Add the following PPE configuration in airoha_ppe_hw_init routine:
> - 6RD hw offloading is currently not supported by Netfilter flowtable.
> Disable explicitly PPE 6RD offloading in order to prevent PPE to learn
> 6RD flows and eventually interrupt the traffic.
> - Add missing PPE bind rate configuration for L3 and L2 traffic.
> PPE bind rate configuration specifies the pps threshold to move a PPE
> entry state from UNBIND to BIND. Without this configuration this value
> is random.
> - Set ageing thresholds to the values used in the vendor SDK in order to
> improve connection stability under load and avoid packet loss caused by
> fast aging.
>
> [...]
Here is the summary with links:
- [net] net: airoha: Add missing PPE configurations in airoha_ppe_hw_init()
https://git.kernel.org/netdev/net/c/b9d8b856689d
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] net: wwan: t7xx: validate port_count against message length in t7xx_port_enum_msg_handler
From: Willy Tarreau @ 2026-04-14 13:17 UTC (permalink / raw)
To: Paolo Abeni
Cc: Pavitra Jha, chandrashekar.devegowda, linux-wwan, netdev, stable
In-Reply-To: <3b67dedb-3472-4322-9a30-32bf8e3cef99@redhat.com>
On Tue, Apr 14, 2026 at 11:41:54AM +0200, Paolo Abeni wrote:
> On 4/11/26 10:39 AM, 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 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: 1e3e8eb9b6e3 ("net: wwan: t7xx: Add control DMA interface")
>
> Wrong fixes tag:
>
> fatal: ambiguous argument '1e3e8eb9b6e3': unknown revision or path not
> in the working tree.
Interesting, there isn't a single digit correct here! The matching one
I'm finding based on the subject is:
39d439047f1d ("net: wwan: t7xx: Add control DMA interface")
Willy
> > diff --git a/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c b/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c
> > index ae632ef96..d984a688d 100644
> > --- a/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c
> > +++ b/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c
> > @@ -124,7 +124,7 @@ static int fsm_ee_message_handler(struct t7xx_port *port, struct t7xx_fsm_ctl *c
> > * * 0 - Success.
> > * * -EFAULT - Message check failure.
> > */
> > -int t7xx_port_enum_msg_handler(struct t7xx_modem *md, void *msg)
> > +int t7xx_port_enum_msg_handler(struct t7xx_modem *md, void *msg, size_t msg_len)
>
> Undocumented new argument
>
> /P
^ permalink raw reply
* Re: [PATCH net] net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup()
From: Lorenzo Bianconi @ 2026-04-14 13:15 UTC (permalink / raw)
To: Simon Horman
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260414124641.754059-1-horms@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2536 bytes --]
> From: 'Simon Horman' <horms@kernel.org>
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev
> ---
> net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup()
>
> This commit adds a poll loop in airoha_ppe_offload_setup() to wait for the NPU
> PPE configuration to complete before running airoha_ppe_hw_init().
>
> > diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> > index c2c32b6833df9..52199f6b39f9b 100644
> > --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> > +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> [ ... ]
> > @@ -1340,6 +1341,13 @@ static int airoha_ppe_offload_setup(struct airoha_eth *eth)
> > if (err)
> > goto error_npu_put;
> >
> > + /* Wait for NPU PPE configuration to complete */
> > + err = read_poll_timeout(airoha_fe_rr, val, val, USEC_PER_MSEC,
> > + 100 * USEC_PER_MSEC, false, eth,
> > + REG_PPE_PPE_FLOW_CFG(0));
>
> If the SoC has multiple PPE instances, is it sufficient to only wait for
> REG_PPE_PPE_FLOW_CFG(0)?
>
> Later in airoha_ppe_hw_init(), the code iterates up to eth->soc->num_ppe,
> initializing all available instances:
>
> drivers/net/ethernet/airoha/airoha_ppe.c:airoha_ppe_hw_init() {
> ...
> for (i = 0; i < eth->soc->num_ppe; i++) {
> ...
> airoha_fe_wr(eth, REG_PPE_TB_BASE(i),
> ppe->foe_dma + sram_tb_size);
> ...
> }
ack, let me look into it, I will post a v2.
>
> If we only poll PPE 0, could the driver race with the NPU firmware's
> initialization of subsequent PPEs?
>
> Additionally, does this poll condition properly ensure the hardware is ready?
> Since the break condition is simply `val`, it exits immediately if the register
> contains any non-zero value.
>
> If the register retains a non-zero value from a previous session (like across
> driver reloads), or if an unclocked domain returns 0xFFFFFFFF, this poll might
> succeed immediately and bypass the wait.
>
> Could we clear the register before polling, or wait for a specific bit instead?
I guess check val != 0 is enough since we reset the FE block and defualt
register value is 0 for both REG_PPE_PPE_FLOW_CFG(0) and
REG_PPE_PPE_FLOW_CFG(1).
Regards,
Lorenzo
>
> > + if (err)
> > + goto error_npu_put;
> > +
> > ppe_num_stats_entries = airoha_ppe_get_total_num_stats_entries(ppe);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next] ice: call netif_keep_dst() once when entering switchdev mode
From: Holda, Patryk @ 2026-04-14 13:13 UTC (permalink / raw)
To: Simon Horman, Loktionov, Aleksandr
Cc: intel-wired-lan@lists.osuosl.org, Nguyen, Anthony L,
netdev@vger.kernel.org, Szycik, Marcin
In-Reply-To: <20260403124133.GA94926@horms.kernel.org>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Simon Horman
> Sent: Friday, April 3, 2026 2:42 PM
> To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> Cc: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; netdev@vger.kernel.org; Szycik, Marcin
> <marcin.szycik@intel.com>
> Subject: Re: [Intel-wired-lan] [PATCH iwl-next] ice: call netif_keep_dst() once
> when entering switchdev mode
>
> On Fri, Mar 27, 2026 at 08:22:36AM +0100, Aleksandr Loktionov wrote:
> > From: Marcin Szycik <marcin.szycik@intel.com>
> >
> > netif_keep_dst() only needs to be called once for the uplink VSI, not
> > once for each port representor. Move it from ice_eswitch_setup_repr()
> > to ice_eswitch_enable_switchdev().
> >
> > Fixes: defd52455aee ("ice: do Tx through PF netdev in slow-path")
>
> This problem seems to predate the cited commit.
>
> > Signed-off-by: Marcin Szycik <marcin.szycik@intel.com>
> > Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Patryk Holda <patryk.holda@intel.com>
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Alexis Lothoré @ 2026-04-14 13:12 UTC (permalink / raw)
To: Andrey Konovalov, Alexis Lothoré (eBPF Foundation)
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
David S. Miller, David Ahern, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, linux-kernel, netdev, linux-kselftest,
linux-stm32, linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CA+fCnZfubV6LgRjO3NQvhrG2Q5o0ftkFFupLWVYS50XDnmCaog@mail.gmail.com>
Hi Andrey, thanks for the prompt review !
On Tue Apr 14, 2026 at 12:19 AM CEST, Andrey Konovalov wrote:
> On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation)
> <alexis.lothore@bootlin.com> wrote:
>>
[...]
>> +#ifdef CONFIG_KASAN_GENERIC
>> +void __asan_load1(void *p);
>> +void __asan_store1(void *p);
>> +void __asan_load2(void *p);
>> +void __asan_store2(void *p);
>> +void __asan_load4(void *p);
>> +void __asan_store4(void *p);
>> +void __asan_load8(void *p);
>> +void __asan_store8(void *p);
>> +void __asan_load16(void *p);
>> +void __asan_store16(void *p);
>> +#endif /* CONFIG_KASAN_GENERIC */
>
> This looks ugly, let's not do this unless it's really required.
>
> You can just use kasan_check_read/write() instead - these are public
> wrappers around the same shadow memory checking functions. And they
> also work with the SW_TAGS mode, in case the BPF would want to use
> that mode at some point. (For HW_TAGS, we only have kasan_check_byte()
> that checks a single byte, but it can be extended in the future if
> required to be used by BPF.)
ACK, I'll try to use those kasan_check_read and kasan_check_write rather
than __asan_{load,store}X.
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 1/3] i40e: prepare for XDP metadata ops support
From: Holda, Patryk @ 2026-04-14 13:12 UTC (permalink / raw)
To: Loktionov, Aleksandr, Kohei Enju,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org
Cc: Nguyen, Anthony L, Kitszel, Przemyslaw, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
kohei.enju@gmail.com
In-Reply-To: <IA3PR11MB89861AD556C1C4D863DD4F3EE54CA@IA3PR11MB8986.namprd11.prod.outlook.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Loktionov, Aleksandr
> Sent: Friday, March 20, 2026 7:57 AM
> To: Kohei Enju <kohei@enjuk.jp>; intel-wired-lan@lists.osuosl.org;
> netdev@vger.kernel.org
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; kohei.enju@gmail.com
> Subject: Re: [Intel-wired-lan] [PATCH iwl-next v1 1/3] i40e: prepare for XDP
> metadata ops support
>
>
>
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> > Of Kohei Enju
> > Sent: Thursday, March 19, 2026 6:17 PM
> > To: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org
> > Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> > Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> > <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric
> > Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>;
> Paolo
> > Abeni <pabeni@redhat.com>; kohei.enju@gmail.com; Kohei Enju
> > <kohei@enjuk.jp>
> > Subject: [Intel-wired-lan] [PATCH iwl-next v1 1/3] i40e: prepare for
> > XDP metadata ops support
> >
> > Prepare 'struct i40e_xdp_buff' that contains an xdp_buff and a pointer
> > to i40e_rx_desc in order to pass the RX descriptor to the XDP kfuncs.
> > Also in ZC path, use XSK_CHECK_PRIV_TYPE() to ensure i40e_xdp_buff
> > doesn't exceed the offset of cb in xdp_buff_xsk.
> >
> > No functional changes.
> >
> > Signed-off-by: Kohei Enju <kohei@enjuk.jp>
> > ---
> > drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
> > drivers/net/ethernet/intel/i40e/i40e_txrx.c | 5 ++++-
> > drivers/net/ethernet/intel/i40e/i40e_txrx.h | 7 ++++++-
> > drivers/net/ethernet/intel/i40e/i40e_xsk.c | 12 ++++++++++++
> > 4 files changed, 23 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> > b/drivers/net/ethernet/intel/i40e/i40e_main.c
> > index 31a42ee18aa0..7966d9cb8009 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> > @@ -3619,7 +3619,7 @@ static int i40e_configure_rx_ring(struct
> > i40e_ring *ring)
> > }
> >
> > skip:
> > - xdp_init_buff(&ring->xdp, xdp_frame_sz, &ring->xdp_rxq);
> > + xdp_init_buff(&ring->xdp_ctx.xdp, xdp_frame_sz, &ring-
> > >xdp_rxq);
> >
> > rx_ctx.dbuff = DIV_ROUND_UP(ring->rx_buf_len,
> > BIT_ULL(I40E_RXQ_CTX_DBUFF_SHIFT));
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> > b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> > index 4ffdb007c41a..cfaf724ee7ff 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> > @@ -2438,10 +2438,11 @@ static int i40e_clean_rx_irq(struct i40e_ring
> > *rx_ring, int budget,
> > unsigned int *rx_cleaned)
> > {
> > unsigned int total_rx_bytes = 0, total_rx_packets = 0;
>
> ...
>
> > xdp_res = i40e_run_xdp_zc(rx_ring, first, xdp_prog);
> > i40e_handle_xdp_result_zc(rx_ring, first, rx_desc,
> &rx_packets,
> > &rx_bytes, xdp_res, &failure);
> > --
> > 2.51.0
>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Patryk Holda <patryk.holda@intel.com>
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix max TX packet length configuration
From: Paolo Abeni @ 2026-04-14 13:04 UTC (permalink / raw)
To: Lorenzo Bianconi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260412-airoha-fix-max-mtu-v1-1-333030d0a564@kernel.org>
On 4/12/26 10:09 AM, Lorenzo Bianconi wrote:
> According to the Airoha documentation, REG_GDM_LEN_CFG() register does not
> include FCS length. Fix MTU configuration removing ETH_FCS_LEN from
> maximum TX packet length configuration.
>
> Fixes: 54d989d58d2ac ("net: airoha: Move min/max packet len configuration in airoha_dev_open()")
> Fixes: 03b1b69f0662c ("net: airoha: Introduce airoha_dev_change_mtu callback")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index c14cdce588a7..a81ffda72b39 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1629,9 +1629,9 @@ static void airoha_update_hw_stats(struct airoha_gdm_port *port)
>
> static int airoha_dev_open(struct net_device *dev)
> {
> - int err, len = ETH_HLEN + dev->mtu + ETH_FCS_LEN;
> struct airoha_gdm_port *port = netdev_priv(dev);
> struct airoha_qdma *qdma = port->qdma;
> + int err, len = ETH_HLEN + dev->mtu;
Sashiko noted that the above may cause regressions, dropping max MTU
vlan frames.
/P
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix max TX packet length configuration
From: Lorenzo Bianconi @ 2026-04-14 13:04 UTC (permalink / raw)
To: Simon Horman
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260414124011.751922-1-horms@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]
> From: 'Simon Horman' <horms@kernel.org>
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev
> ---
> net: airoha: Fix max TX packet length configuration
>
> This commit fixes the MTU configuration for the Airoha driver by removing
> ETH_FCS_LEN from the maximum TX packet length, matching the hardware
> documentation which states the register does not include the FCS length.
>
> > diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> > index c14cdce588a7c..a81ffda72b39f 100644
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> > @@ -1629,9 +1629,9 @@ static void airoha_update_hw_stats(struct airoha_gdm_port *port)
> >
> > static int airoha_dev_open(struct net_device *dev)
> > {
> > - int err, len = ETH_HLEN + dev->mtu + ETH_FCS_LEN;
> > struct airoha_gdm_port *port = netdev_priv(dev);
> > struct airoha_qdma *qdma = port->qdma;
> > + int err, len = ETH_HLEN + dev->mtu;
>
> Does this regression cause MTU-sized VLAN-tagged frames to be dropped by the
> hardware?
>
> By limiting the frame size to ETH_HLEN + dev->mtu, the maximum allowed length
> becomes 1514 bytes for a standard 1500 MTU. An Ethernet frame containing a
> standard 802.1Q VLAN tag and a maximum-sized 1500-byte IP payload requires an
> 18-byte L2 header, making the total frame size 1518 bytes (excluding FCS).
>
> Previously, the inclusion of ETH_FCS_LEN inadvertently provided the 4-byte
> headroom needed to accommodate a single VLAN tag.
>
> Could the configuration explicitly account for VLAN headers using VLAN_ETH_HLEN
> instead?
ack, thx for pointing this out. I will fix it in v2.
Regards,
Lorenzo
>
> [ ... ]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [net,PATCH v3 2/2] net: ks8851: Avoid excess softirq scheduling
From: Sebastian Andrzej Siewior @ 2026-04-14 13:02 UTC (permalink / raw)
To: Marek Vasut
Cc: netdev, stable, David S. Miller, Andrew Lunn, Eric Dumazet,
Jakub Kicinski, Nicolai Buchwitz, Paolo Abeni, Ronald Wahl,
Yicong Hui, linux-kernel
In-Reply-To: <20260414103327.113500-2-marex@nabladev.com>
On 2026-04-14 12:32:53 [+0200], Marek Vasut wrote:
> The code injects a packet into netif_rx() repeatedly, which will add
> it to its internal NAPI and schedule a softirq, and process it. It is
> more efficient to queue multiple packets and process them all at the
> local_bh_enable() time.
>
> Fixes: e0863634bf9f ("net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs")
> Cc: stable@vger.kernel.org
> Signed-off-by: Marek Vasut <marex@nabladev.com>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Sebastian
^ permalink raw reply
* Re: [PATCH iwl-next v2 1/8] ixgbe: lower IXGBE_ITR_ADAPTIVE_MAX_USECS to prevent RX starvation
From: Simon Horman @ 2026-04-14 12:58 UTC (permalink / raw)
To: aleksandr.loktionov
Cc: 'Simon Horman', intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260408131216.2662245-2-aleksandr.loktionov@intel.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
ixgbe: lower IXGBE_ITR_ADAPTIVE_MAX_USECS to prevent RX starvation
The patch lowers IXGBE_ITR_ADAPTIVE_MAX_USECS from 126 to 84 to prevent
descriptor ring starvation under sustained full-line-rate bulk RX traffic.
It states that this provides enough headroom to drain the ring before it wraps.
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> index 59a1cee40b436..eedee3b2e72c8 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> @@ -475,7 +475,7 @@ static inline unsigned int ixgbe_rx_pg_order(struct ixgbe_ring *ring)
>
> #define IXGBE_ITR_ADAPTIVE_MIN_INC 2
> #define IXGBE_ITR_ADAPTIVE_MIN_USECS 10
> -#define IXGBE_ITR_ADAPTIVE_MAX_USECS 126
> +#define IXGBE_ITR_ADAPTIVE_MAX_USECS 84
Will the hardware still be configured with a 126 us delay during bulk traffic?
Looking at ixgbe_update_itr(), when traffic is categorized as bulk
(packets >= 256), itr is initialized to IXGBE_ITR_ADAPTIVE_BULK (0).
For a 10Gbps link, avg_wire_size plateaus at 32256:
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:ixgbe_update_itr() {
...
} else {
/* plateau at a limit of 8K ints/sec */
avg_wire_size = 32256;
}
...
}
The itr is then calculated and updated directly:
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:ixgbe_update_itr() {
...
switch (q_vector->adapter->link_speed) {
case IXGBE_LINK_SPEED_10GB_FULL:
case IXGBE_LINK_SPEED_100_FULL:
default:
itr += DIV_ROUND_UP(avg_wire_size,
IXGBE_ITR_ADAPTIVE_MIN_INC * 256) *
IXGBE_ITR_ADAPTIVE_MIN_INC;
break;
...
}
With IXGBE_ITR_ADAPTIVE_MIN_INC being 2, the calculation is
DIV_ROUND_UP(32256, 512) * 2, which equals exactly 126.
There is no clamping against IXGBE_ITR_ADAPTIVE_MAX_USECS applied after this
bulk calculation, so ring_container->itr becomes 126.
Later, in ixgbe_set_itr(), the final ITR is determined by taking the minimum
between the rx and tx values:
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:ixgbe_set_itr() {
...
new_itr = min(q_vector->rx.itr, q_vector->tx.itr);
...
}
If the TX ring is idle or operating in latency mode, it will have the
IXGBE_ITR_ADAPTIVE_LATENCY flag (0x80) set. Even though its base value is
clamped to 84, the latency flag makes it numerically 212.
Does this mean min(126, 212) will return the RX bulk value of 126, leaving
the interrupt delay at 126 us and descriptor ring starvation unresolved?
> #define IXGBE_ITR_ADAPTIVE_LATENCY 0x80
> #define IXGBE_ITR_ADAPTIVE_BULK 0x00
^ permalink raw reply
* Re: [net,PATCH v3 1/2] net: ks8851: Reinstate disabling of BHs around IRQ handler
From: Sebastian Andrzej Siewior @ 2026-04-14 12:57 UTC (permalink / raw)
To: Marek Vasut
Cc: netdev, stable, David S. Miller, Andrew Lunn, Eric Dumazet,
Jakub Kicinski, Nicolai Buchwitz, Paolo Abeni, Ronald Wahl,
Yicong Hui, linux-kernel
In-Reply-To: <20260414103327.113500-1-marex@nabladev.com>
On 2026-04-14 12:32:52 [+0200], Marek Vasut wrote:
> If CONFIG_PREEMPT_RT=y is set AND the driver executes ks8851_irq() AND
> KSZ_ISR register bit IRQ_RXI is set AND ks8851_rx_pkts() detects that
> there are packets in the RX FIFO, then netdev_alloc_skb_ip_align() is
> called to allocate SKBs. If netdev_alloc_skb_ip_align() is called with
> BH enabled, local_bh_enable() at the end of netdev_alloc_skb_ip_align()
> will call __local_bh_enable_ip(), which will call __do_softirq(), which
> may trigger net_tx_action() softirq, which may ultimately call the xmit
> callback ks8851_start_xmit_par(). The ks8851_start_xmit_par() will try
> to lock struct ks8851_net_par .lock spinlock, which is already locked
> by ks8851_irq() from which ks8851_start_xmit_par() was called. This
> leads to a deadlock, which is reported by the kernel, including a trace
> listed below.
#1 [received RX packet and a] TX packet has been sent
#2 Driver enables TX queue via netif_wake_queue() which schedules TX
softirq to queue packets for this device.
#2 After spin_unlock_bh(&ks->statelock) the pending softirqs will be
processed
#3 This deadlocks because of recursive locking via ks8851_net::lock in
ks8851_irq() and ks8851_start_xmit_par().
This is what happens since commit 0913ec336a6c0 ("net: ks8851: Fix
deadlock with the SPI chip variant"). Before that commit the softirq
execution will be picked up by netdev_alloc_skb_ip_align() and requires
PREEMPT_RT and a RX packet in #1 to trigger the deadlock.
> Fix the problem by disabling BH around critical sections, including the
> IRQ handler, thus preventing the net_tx_action() softirq from triggering
> during these critical sections. The net_tx_action() softirq is triggered
> at the end of the IRQ handler, once all the other IRQ handler actions have
> been completed.
>
> __schedule from schedule_rtlock+0x1c/0x34
> schedule_rtlock from rtlock_slowlock_locked+0x548/0x904
> rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c
> rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8
> ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44
> netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188
> dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c
> sch_direct_xmit from __qdisc_run+0x1f8/0x4ec
> __qdisc_run from qdisc_run+0x1c/0x28
> qdisc_run from net_tx_action+0x1f0/0x268
> net_tx_action from handle_softirqs+0x1a4/0x270
> handle_softirqs from __local_bh_enable_ip+0xcc/0xe0
> __local_bh_enable_ip from __alloc_skb+0xd8/0x128
> __alloc_skb from __netdev_alloc_skb+0x3c/0x19c
> __netdev_alloc_skb from ks8851_irq+0x388/0x4d4
> ks8851_irq from irq_thread_fn+0x24/0x64
> irq_thread_fn from irq_thread+0x178/0x28c
> irq_thread from kthread+0x12c/0x138
> kthread from ret_from_fork+0x14/0x28
The backtrace here and the description is based on an older kernel.
However
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Fixes: e0863634bf9f ("net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs")
> Cc: stable@vger.kernel.org
> Signed-off-by: Marek Vasut <marex@nabladev.com>
Sebastian
^ permalink raw reply
* Re: [PATCH net] net: airoha: Add missing PPE configurations in airoha_ppe_hw_init()
From: Simon Horman @ 2026-04-14 12:48 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260412-airoha_ppe_hw_init-missing-bits-v1-1-06ac670819e3@kernel.org>
On Sun, Apr 12, 2026 at 10:43:26AM +0200, Lorenzo Bianconi wrote:
> Add the following PPE configuration in airoha_ppe_hw_init routine:
> - 6RD hw offloading is currently not supported by Netfilter flowtable.
> Disable explicitly PPE 6RD offloading in order to prevent PPE to learn
> 6RD flows and eventually interrupt the traffic.
> - Add missing PPE bind rate configuration for L3 and L2 traffic.
> PPE bind rate configuration specifies the pps threshold to move a PPE
> entry state from UNBIND to BIND. Without this configuration this value
> is random.
> - Set ageing thresholds to the values used in the vendor SDK in order to
> improve connection stability under load and avoid packet loss caused by
> fast aging.
>
> Fixes: 00a7678310fe3 ("net: airoha: Introduce flowtable offload support")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net] net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup()
From: Simon Horman @ 2026-04-14 12:46 UTC (permalink / raw)
To: lorenzo
Cc: 'Simon Horman', andrew+netdev, davem, edumazet, kuba,
pabeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260412-airoha-wait-for-npu-config-offload-setup-v1-1-f4e0aa2a5d85@kernel.org>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup()
This commit adds a poll loop in airoha_ppe_offload_setup() to wait for the NPU
PPE configuration to complete before running airoha_ppe_hw_init().
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index c2c32b6833df9..52199f6b39f9b 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
[ ... ]
> @@ -1340,6 +1341,13 @@ static int airoha_ppe_offload_setup(struct airoha_eth *eth)
> if (err)
> goto error_npu_put;
>
> + /* Wait for NPU PPE configuration to complete */
> + err = read_poll_timeout(airoha_fe_rr, val, val, USEC_PER_MSEC,
> + 100 * USEC_PER_MSEC, false, eth,
> + REG_PPE_PPE_FLOW_CFG(0));
If the SoC has multiple PPE instances, is it sufficient to only wait for
REG_PPE_PPE_FLOW_CFG(0)?
Later in airoha_ppe_hw_init(), the code iterates up to eth->soc->num_ppe,
initializing all available instances:
drivers/net/ethernet/airoha/airoha_ppe.c:airoha_ppe_hw_init() {
...
for (i = 0; i < eth->soc->num_ppe; i++) {
...
airoha_fe_wr(eth, REG_PPE_TB_BASE(i),
ppe->foe_dma + sram_tb_size);
...
}
If we only poll PPE 0, could the driver race with the NPU firmware's
initialization of subsequent PPEs?
Additionally, does this poll condition properly ensure the hardware is ready?
Since the break condition is simply `val`, it exits immediately if the register
contains any non-zero value.
If the register retains a non-zero value from a previous session (like across
driver reloads), or if an unclocked domain returns 0xFFFFFFFF, this poll might
succeed immediately and bypass the wait.
Could we clear the register before polling, or wait for a specific bit instead?
> + if (err)
> + goto error_npu_put;
> +
> ppe_num_stats_entries = airoha_ppe_get_total_num_stats_entries(ppe);
^ permalink raw reply
* Re: [PATCH net 1/1] ipv6: xfrm6: release dst on error in xfrm6_rcv_encap()
From: Simon Horman @ 2026-04-14 12:43 UTC (permalink / raw)
To: n05ec
Cc: 'Simon Horman', netdev, steffen.klassert, herbert, davem,
dsahern, edumazet, kuba, pabeni, sd, yifanwucs, tomapufckgml,
yuantan098, bird, caoruide123, zylzyl2333
In-Reply-To: <fc06a81e1c1cbbb3e918825a718046cb18204f3c.1775886483.git.zylzyl2333@gmail.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
ipv6: xfrm6: release dst on error in xfrm6_rcv_encap()
This commit fixes a dst entry leak in xfrm6_rcv_encap() by ensuring
the dst is released when ip6_route_input_lookup() returns an error route.
> diff --git a/net/ipv6/xfrm6_protocol.c b/net/ipv6/xfrm6_protocol.c
> index ea2f805d3b014..9b586fcec4850 100644
> --- a/net/ipv6/xfrm6_protocol.c
> +++ b/net/ipv6/xfrm6_protocol.c
> @@ -88,8 +88,10 @@ int xfrm6_rcv_encap(struct sk_buff *skb, int nexthdr, __be32 spi,
>
> dst = ip6_route_input_lookup(dev_net(skb->dev), skb->dev, &fl6,
> skb, flags);
This isn't a bug introduced by this patch, but is it possible for skb->dev
to be NULL here?
When ESP packets are delivered over TCP, they are processed asynchronously
via handle_esp() in net/xfrm/espintcp.c. This dynamically resolves skb->dev
using dev_get_by_index_rcu(). If the interface was removed before this runs,
it returns NULL.
Because TCP receive paths drop the skb's dst entry, skb_dst(skb) is NULL.
When handle_esp() passes the skb to xfrm6_rcv_encap(), it enters the
!skb_dst(skb) block and unconditionally accesses skb->dev->ifindex and
calls dev_net(skb->dev).
Could this result in a NULL pointer dereference if the interface is torn
down while packets are being processed asynchronously?
> - if (dst->error)
> + if (dst->error) {
> + dst_release(dst);
> goto drop;
> + }
> skb_dst_set(skb, dst);
> }
>
^ permalink raw reply
* Re: [patch 31/38] parisc: Select ARCH_HAS_RANDOM_ENTROPY
From: Helge Deller @ 2026-04-14 12:41 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: linux-parisc, 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, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120319.658485572@kernel.org>
On 4/10/26 14:21, Thomas Gleixner wrote:
> The only remaining non-architecture usage of get_cycles() is to provide
> random_get_entropy().
>
> Switch parisc over to the new scheme of selecting ARCH_HAS_RANDOM_ENTROPY
> and providing random_get_entropy() in asm/random.h.
>
> Add 'asm/timex.h' includes to the relevant files, so the global include can
> be removed once all architectures are converted over.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Helge Deller <deller@gmx.de>
> Cc: linux-parisc@vger.kernel.org
> ---
> arch/parisc/Kconfig | 1 +
> arch/parisc/include/asm/random.h | 12 ++++++++++++
> arch/parisc/include/asm/timex.h | 6 ------
> arch/parisc/kernel/processor.c | 1 +
> arch/parisc/kernel/time.c | 1 +
> 5 files changed, 15 insertions(+), 6 deletions(-)
I tested this series on parisc.
Works as expected.
Tested-by: Helge Deller <deller@gmx.de>
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Andrew Lunn @ 2026-04-14 12:40 UTC (permalink / raw)
To: Marek Vasut
Cc: Fidelio Lawson, Woojung Huh, UNGLinuxDriver, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Marek Vasut, Maxime Chevallier, Simon Horman, Heiner Kallweit,
Russell King, netdev, linux-kernel, Fidelio Lawson
In-Reply-To: <ea90a671-70be-4d89-b842-1e54d687336f@nabladev.com>
On Tue, Apr 14, 2026 at 01:05:49PM +0200, Marek Vasut wrote:
> On 4/14/26 11:12 AM, Fidelio Lawson wrote:
> > Implement the "Module 3: Equalizer fix for short cables" erratum from
> > Microchip document DS80000687C for KSZ87xx switches.
> >
> > The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
> > where the PHY receiver equalizer may amplify high-amplitude signals
> > excessively, resulting in internal distortion and link establishment
> > failures.
> >
> > KSZ87xx devices require a workaround for the Module 3 low-loss cable
> > condition, controlled through the switch TABLE_LINK_MD_V indirect
> > registers.
> >
> > The affected registers are part of the switch address space and are not
> > directly accessible from the PHY driver. To keep the PHY-facing API
> > clean and avoid leaking switch-specific details, model this errata
> > control as vendor-specific Clause 22 PHY registers.
> >
> > A vendor-specific Clause 22 PHY register is introduced as a mode
> > selector in PHY_REG_LOW_LOSS_CTRL, and ksz8_r_phy() / ksz8_w_phy()
> > translate accesses to these bits into the appropriate indirect
> > TABLE_LINK_MD_V accesses.
> >
> > The control register defines the following modes:
> > 0: disabled (default behavior)
> > 1: EQ training workaround
> > 2: LPF 90 MHz
> > 3: LPF 62 MHz
> > 4: LPF 55 MHz
> > 5: LPF 44 MHz
> I may not fully understand this, but aren't the EQ and LPF settings
> orthogonal ?
What is the real life experience using this feature? Is it needed for
1cm cables, but most > 1m cables are O.K with the defaults? Do we need
all these configuration options? How is a user supposed to discover
the different options? Can we simplify it down to a Boolean?
Ethernet is just supposed to work with any valid length of cable,
KISS. So maybe we should try to keep this feature KISS. Just tell the
driver it is a short cable, pick different defaults which should work
with any short cable?
A boolean should also help with making this tunable reusable with
other devices. It is unlikely any other devices have these same
configuration options, unless it is from the same vendor.
Andrew
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix max TX packet length configuration
From: Simon Horman @ 2026-04-14 12:40 UTC (permalink / raw)
To: lorenzo
Cc: 'Simon Horman', andrew+netdev, davem, edumazet, kuba,
pabeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260412-airoha-fix-max-mtu-v1-1-333030d0a564@kernel.org>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
net: airoha: Fix max TX packet length configuration
This commit fixes the MTU configuration for the Airoha driver by removing
ETH_FCS_LEN from the maximum TX packet length, matching the hardware
documentation which states the register does not include the FCS length.
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index c14cdce588a7c..a81ffda72b39f 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1629,9 +1629,9 @@ static void airoha_update_hw_stats(struct airoha_gdm_port *port)
>
> static int airoha_dev_open(struct net_device *dev)
> {
> - int err, len = ETH_HLEN + dev->mtu + ETH_FCS_LEN;
> struct airoha_gdm_port *port = netdev_priv(dev);
> struct airoha_qdma *qdma = port->qdma;
> + int err, len = ETH_HLEN + dev->mtu;
Does this regression cause MTU-sized VLAN-tagged frames to be dropped by the
hardware?
By limiting the frame size to ETH_HLEN + dev->mtu, the maximum allowed length
becomes 1514 bytes for a standard 1500 MTU. An Ethernet frame containing a
standard 802.1Q VLAN tag and a maximum-sized 1500-byte IP payload requires an
18-byte L2 header, making the total frame size 1518 bytes (excluding FCS).
Previously, the inclusion of ETH_FCS_LEN inadvertently provided the 4-byte
headroom needed to accommodate a single VLAN tag.
Could the configuration explicitly account for VLAN headers using VLAN_ETH_HLEN
instead?
[ ... ]
^ permalink raw reply
* Re: [PATCH net 1/1] ipv6: xfrm6: release dst on error in xfrm6_rcv_encap()
From: Simon Horman @ 2026-04-14 12:33 UTC (permalink / raw)
To: Ren Wei
Cc: netdev, steffen.klassert, herbert, davem, dsahern, edumazet, kuba,
pabeni, sd, yifanwucs, tomapufckgml, yuantan098, bird,
caoruide123, zylzyl2333
In-Reply-To: <fc06a81e1c1cbbb3e918825a718046cb18204f3c.1775886483.git.zylzyl2333@gmail.com>
On Sun, Apr 12, 2026 at 01:07:54PM +0800, Ren Wei wrote:
> From: Yilin Zhu <zylzyl2333@gmail.com>
>
> xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not
> already have a dst attached. ip6_route_input_lookup() returns a
> referenced dst entry even when the lookup resolves to an error route.
>
> If dst->error is set, xfrm6_rcv_encap() drops the skb without attaching
> the dst to the skb and without releasing the reference returned by the
> lookup. Repeated packets hitting this path therefore leak dst entries.
>
> Release the dst before jumping to the drop path.
>
> Fixes: 0146dca70b87 ("xfrm: add support for UDPv6 encapsulation of ESP")
> 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: Ruide Cao <caoruide123@gmail.com>
> Signed-off-by: Yilin Zhu <zylzyl2333@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> ---
> net/ipv6/xfrm6_protocol.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Simon Horman <horms@kernel.org>
^ 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