* 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
* linux-next: manual merge of the bpf-next tree with the origin tree
From: Mark Brown @ 2026-04-14 12:18 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf,
Networking
Cc: Joel Fernandes, Kumar Kartikeya Dwivedi,
Linux Kernel Mailing List, Linux Next Mailing List,
Paul E. McKenney
[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
include/linux/rcupdate.h
between commit:
ad6ef775cbeff ("rcu-tasks: Document that RCU Tasks Trace grace periods now imply RCU grace periods")
from the origin tree and commit:
57b23c0f612dc ("bpf: Retire rcu_trace_implies_rcu_gp()")
from the bpf-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --combined include/linux/rcupdate.h
index 18a85c30fd4f3,bfa765132de85..0000000000000
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@@ -205,15 -205,6 +205,6 @@@ static inline void exit_tasks_rcu_start
static inline void exit_tasks_rcu_finish(void) { }
#endif /* #else #ifdef CONFIG_TASKS_RCU_GENERIC */
- /**
- * rcu_trace_implies_rcu_gp - does an RCU Tasks Trace grace period imply an RCU grace period?
- *
- * Now that RCU Tasks Trace is implemented in terms of SRCU-fast, a
- * call to synchronize_rcu_tasks_trace() is guaranteed to imply at least
- * one call to synchronize_rcu().
- */
- static inline bool rcu_trace_implies_rcu_gp(void) { return true; }
-
/**
* cond_resched_tasks_rcu_qs - Report potential quiescent states to RCU
*
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH iwl-net] i40e: keep q_vectors array in sync with channel count changes
From: Maciej Fijalkowski @ 2026-04-14 12:14 UTC (permalink / raw)
To: intel-wired-lan
Cc: netdev, magnus.karlsson, kuba, pabeni, horms, przemyslaw.kitszel,
jacob.e.keller, Maciej Fijalkowski
For the main VSI, i40e_set_num_rings_in_vsi() always derives
num_q_vectors from pf->num_lan_msix. At the same time, ethtool -L stores
the user requested channel count in vsi->req_queue_pairs and the queue
setup path uses that value for the effective number of queue pairs.
This leaves queue and vector counts out of sync after shrinking channel
count via ethtool -L. The active queue configuration is reduced, but the
VSI still keeps the full PF-sized q_vector topology.
That mismatch breaks reconfiguration flows which rely on vector/NAPI
state matching the effective channel configuration. In particular,
toggling /sys/class/net/<dev>/threaded after reducing the channel count
can hang, and later channel-count changes can fail because VSI reinit
does not rebuild q_vectors to match the new vector count.
Fix this by making the main VSI num_q_vectors follow the effective
requested channel count, capped by the available MSI-X vectors. Update
i40e_vsi_reinit_setup() to rebuild q_vectors during VSI reinit so the
vector topology is refreshed together with the ring arrays when channel
count changes.
Keep alloc_queue_pairs unchanged and based on pf->num_lan_qps so the VSI
retains its full queue capacity.
Selftest napi_threaded.py was originally used when Jakub reported hang
on /sys/class/net/<dev>/threaded toggle. In order to make it pass on
i40e, use persistent NAPI configuration for q_vector NAPIs so NAPI
identity and threaded settings survive q_vector reallocation across
channel-count changes. This is achieved by using netif_napi_add_config()
when configuring q_vectors.
$ export NETIF=ens259f1np1
$ sudo -E env PATH="$PATH" ./tools/testing/selftests/drivers/net/napi_threaded.py
TAP version 13
1..3
ok 1 napi_threaded.napi_init
ok 2 napi_threaded.change_num_queues
ok 3 napi_threaded.enable_dev_threaded_disable_napi_threaded
Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0
Reported-by: Jakub Kicinski <kuba@kernel.org>
Closes: https://lore.kernel.org/intel-wired-lan/20260316133100.6054a11f@kernel.org/
Fixes: d2a69fefd756 ("i40e: Fix changing previously set num_queue_pairs for PFs")
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 34 +++++++++++++++++----
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 926d001b2150..5636ad71f940 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -11403,10 +11403,14 @@ static void i40e_service_timer(struct timer_list *t)
static int i40e_set_num_rings_in_vsi(struct i40e_vsi *vsi)
{
struct i40e_pf *pf = vsi->back;
+ u16 qps;
switch (vsi->type) {
case I40E_VSI_MAIN:
vsi->alloc_queue_pairs = pf->num_lan_qps;
+ qps = vsi->req_queue_pairs ?
+ min_t(u16, vsi->req_queue_pairs, pf->num_lan_qps) :
+ pf->num_lan_qps;
if (!vsi->num_tx_desc)
vsi->num_tx_desc = ALIGN(I40E_DEFAULT_NUM_DESCRIPTORS,
I40E_REQ_DESCRIPTOR_MULTIPLE);
@@ -11414,7 +11418,8 @@ static int i40e_set_num_rings_in_vsi(struct i40e_vsi *vsi)
vsi->num_rx_desc = ALIGN(I40E_DEFAULT_NUM_DESCRIPTORS,
I40E_REQ_DESCRIPTOR_MULTIPLE);
if (test_bit(I40E_FLAG_MSIX_ENA, pf->flags))
- vsi->num_q_vectors = pf->num_lan_msix;
+ vsi->num_q_vectors = max_t(int, 1,
+ min_t(int, qps, pf->num_lan_msix));
else
vsi->num_q_vectors = 1;
@@ -12043,7 +12048,8 @@ static int i40e_vsi_alloc_q_vector(struct i40e_vsi *vsi, int v_idx)
cpumask_copy(&q_vector->affinity_mask, cpu_possible_mask);
if (vsi->netdev)
- netif_napi_add(vsi->netdev, &q_vector->napi, i40e_napi_poll);
+ netif_napi_add_config(vsi->netdev, &q_vector->napi,
+ i40e_napi_poll, v_idx);
/* tie q_vector and vsi together */
vsi->q_vectors[v_idx] = q_vector;
@@ -14265,12 +14271,27 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
pf = vsi->back;
+ if (test_bit(I40E_FLAG_MSIX_ENA, pf->flags)) {
+ i40e_put_lump(pf->irq_pile, vsi->base_vector, vsi->idx);
+ vsi->base_vector = 0;
+ }
+
i40e_put_lump(pf->qp_pile, vsi->base_queue, vsi->idx);
i40e_vsi_clear_rings(vsi);
- i40e_vsi_free_arrays(vsi, false);
+ i40e_vsi_free_q_vectors(vsi);
+ i40e_vsi_free_arrays(vsi, true);
i40e_set_num_rings_in_vsi(vsi);
- ret = i40e_vsi_alloc_arrays(vsi, false);
+
+ ret = i40e_vsi_alloc_arrays(vsi, true);
+ if (ret)
+ goto err_vsi;
+
+ /* Rebuild q_vectors during VSI reinit because the effective channel
+ * count may change num_q_vectors. Keep vector topology aligned with the
+ * queue configuration after ethtool's .set_channels() callback.
+ */
+ ret = i40e_vsi_setup_vectors(vsi);
if (ret)
goto err_vsi;
@@ -14282,7 +14303,7 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
dev_info(&pf->pdev->dev,
"failed to get tracking for %d queues for VSI %d err %d\n",
alloc_queue_pairs, vsi->seid, ret);
- goto err_vsi;
+ goto err_lump;
}
vsi->base_queue = ret;
@@ -14306,7 +14327,6 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
return vsi;
err_rings:
- i40e_vsi_free_q_vectors(vsi);
if (vsi->netdev_registered) {
vsi->netdev_registered = false;
unregister_netdev(vsi->netdev);
@@ -14316,6 +14336,8 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
if (vsi->type == I40E_VSI_MAIN)
i40e_devlink_destroy_port(pf);
i40e_aq_delete_element(&pf->hw, vsi->seid, NULL);
+err_lump:
+ i40e_vsi_free_q_vectors(vsi);
err_vsi:
i40e_vsi_clear(vsi);
return NULL;
--
2.43.0
^ permalink raw reply related
* Re: [syzbot] [lvs?] BUG: sleeping function called from invalid context in ip_vs_conn_expire
From: Jiayuan Chen @ 2026-04-14 12:09 UTC (permalink / raw)
To: syzbot, coreteam, davem, edumazet, fw, horms, ja, kuba,
linux-kernel, lvs-devel, netdev, netfilter-devel, pabeni, pablo,
phil, syzkaller-bugs
In-Reply-To: <69de1743.a00a0220.475f0.0040.GAE@google.com>
On 4/14/26 6:30 PM, syzbot wrote:
[...]
> if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+504e778ddaecd36fdd17@syzkaller.appspotmail.com
>
> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
The problem occurs under PREEMPT_RT. conn_tab_lock pair with spin_lock
has the problem:
conn_tab_lock(...) -> hlist_bl_lock -> preempt_disable() ==>
disables preemption
spin_lock(&cp->lock) -> rt_mutex ==> sleepable under RT, but
preemption is already disabled by conn_tab_lock
> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 16, name: ktimers/0
> preempt_count: 2, expected: 0
> RCU nest depth: 3, expected: 3
> 8 locks held by ktimers/0/16:
> #0: ffffffff8de5f260 (local_bh){.+.+}-{1:3}, at: __local_bh_disable_ip+0x3c/0x420 kernel/softirq.c:163
> #1: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: __local_bh_disable_ip+0x3c/0x420 kernel/softirq.c:163
> #2: ffff8880b8826360 (&base->expiry_lock){+...}-{3:3}, at: spin_lock include/linux/spinlock_rt.h:45 [inline]
> #2: ffff8880b8826360 (&base->expiry_lock){+...}-{3:3}, at: timer_base_lock_expiry kernel/time/timer.c:1502 [inline]
> #2: ffff8880b8826360 (&base->expiry_lock){+...}-{3:3}, at: __run_timer_base+0x120/0x9f0 kernel/time/timer.c:2384
> #3: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
> #3: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:838 [inline]
> #3: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: __rt_spin_lock kernel/locking/spinlock_rt.c:50 [inline]
> #3: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rt_spin_lock+0x1e0/0x400 kernel/locking/spinlock_rt.c:57
> #4: ffffc90000157a80 ((&cp->timer)){+...}-{0:0}, at: call_timer_fn+0xd4/0x5e0 kernel/time/timer.c:1745
> #5: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
> #5: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:838 [inline]
> #5: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: ip_vs_conn_unlink net/netfilter/ipvs/ip_vs_conn.c:315 [inline]
> #5: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: ip_vs_conn_expire+0x257/0x2390 net/netfilter/ipvs/ip_vs_conn.c:1260
> #6: ffffffff8de5f260 (local_bh){.+.+}-{1:3}, at: __local_bh_disable_ip+0x3c/0x420 kernel/softirq.c:163
> #7: ffff888068d4c3f0 (&cp->lock#2){+...}-{3:3}, at: spin_lock include/linux/spinlock_rt.h:45 [inline]
> #7: ffff888068d4c3f0 (&cp->lock#2){+...}-{3:3}, at: ip_vs_conn_unlink net/netfilter/ipvs/ip_vs_conn.c:324 [inline]
> #7: ffff888068d4c3f0 (&cp->lock#2){+...}-{3:3}, at: ip_vs_conn_expire+0xd4a/0x2390 net/netfilter/ipvs/ip_vs_conn.c:1260
> Preemption disabled at:
> [<ffffffff898a6358>] bit_spin_lock include/linux/bit_spinlock.h:38 [inline]
> [<ffffffff898a6358>] hlist_bl_lock+0x18/0x110 include/linux/list_bl.h:149
> CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Tainted: G W L syzkaller #0 PREEMPT_{RT,(full)}
> Tainted: [W]=WARN, [L]=SOFTLOCKUP
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
> Call Trace:
> <TASK>
> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
> __might_resched+0x329/0x480 kernel/sched/core.c:9162
> __rt_spin_lock kernel/locking/spinlock_rt.c:48 [inline]
> rt_spin_lock+0xc2/0x400 kernel/locking/spinlock_rt.c:57
> spin_lock include/linux/spinlock_rt.h:45 [inline]
> ip_vs_conn_unlink net/netfilter/ipvs/ip_vs_conn.c:324 [inline]
> ip_vs_conn_expire+0xd4a/0x2390 net/netfilter/ipvs/ip_vs_conn.c:1260
> call_timer_fn+0x192/0x5e0 kernel/time/timer.c:1748
> expire_timers kernel/time/timer.c:1799 [inline]
> __run_timers kernel/time/timer.c:2374 [inline]
> __run_timer_base+0x6a3/0x9f0 kernel/time/timer.c:2386
> run_timer_base kernel/time/timer.c:2395 [inline]
> run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2405
> handle_softirqs+0x1de/0x6d0 kernel/softirq.c:622
> __do_softirq kernel/softirq.c:656 [inline]
> run_ktimerd+0x69/0x100 kernel/softirq.c:1151
> smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
> kthread+0x388/0x470 kernel/kthread.c:436
> ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
> </TASK>
>
^ permalink raw reply
* Re: [PATCH 2/4] tools: ynl-gen-c: optionally emit structs and helpers
From: Christoph Böhmwalder @ 2026-04-14 12:08 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Jens Axboe, drbd-dev, linux-kernel, Lars Ellenberg,
Philipp Reisner, linux-block, Donald Hunter, Eric Dumazet, netdev
In-Reply-To: <20260413104939.5ef4d9dc@kernel.org>
On Mon, Apr 13, 2026 at 10:49:39AM -0700, Jakub Kicinski wrote:
>On Mon, 13 Apr 2026 13:48:32 +0200 Christoph Böhmwalder wrote:
>> >Can we just commit the code they output and leave the YNL itself be?
>> >Every single legacy family has some weird quirks the point of YNL
>> >is to get rid of them, not support them all..
>>
>> Fair enough, we could also do that. Though the question then becomes
>> whether we want to keep the YAML spec for the "drbd" family (patch 3 of
>> this series) in Documentation/.
>>
>> I would argue it makes sense to keep it around somewhere so that the old
>> family is somehow documented, but obviously that yaml file won't work
>> with the unmodified generator.
>
>To be clear (correct me if I misunderstood) it looked like we would be
>missing out on "automating" things, so extra work would still need to
>be done in the C code / manually written headers. But pure YNL (eg
>Python or Rust) client _would_ work? They could generate correct
>requests and parse responses, right?
I haven't tested this, but yes, a regular YNL client should work with
this spec. The new flags only influence kernel codegen, so a client
that doesn't know about them could still construct valid messages and
parse responses.
However, if we drop patch 2 completely, the new flags won't be in the
genetlink-legacy schema either, so schema validation would fail when
trying to generate.
>If yes, keeping it makes sense. FWIW all the specs we have for "old"
>networking families (routing etc) also don't replace any kernel code.
>They are purely to enable user space libraries in various languages.
>Whether having broad languages support for drbd or you just have one
>well known user space stack - I dunno.
Well, one of the main motivations for porting the current "drbd" family
to YNL is to get rid of the genl_magic infrastructure. We intend to add
a new modernized "drbd2" family, which will be fully YNL-based from the
start.
But we still need to support the current family via a compat path, and
I would much rather have two YNL-based families than one genl_magic and
one YNL-based. Carrying both sounds like a nightmare.
So the spec proposed in this series would never actually be used to
generate a userspace client, if that's what you're asking. We would
continue to use the current libgenl-based approach, with some userspace
compat shims to make it work with YNL. Then, when "drbd2" comes along,
we could "do things properly".
Might also be worth to mention that we are also experimenting with
Rust-based userspace utilities at the moment, so once we have "drbd2",
there will be a real benefit to having multi-language support.
So I'm fine with whichever route you want to take here, as long as
it enables us to move away from genl_magic.
If we decide to carry the "drbd" spec in-tree, that would then pretty
much only be for documentation purposes. Otherwise there would be
generated code where the spec it was generated from is non-existant,
which may be surprising.
>
>> Maybe keep it, but with a comment at the top that notes that
>> - this family is deprecated and "frozen",
>> - the spec is only for documentation purposes, and
>> - the spec doesn't work with the upstream parser?
>
>The past point needs a clarification, I guess..
^ permalink raw reply
* Re: [PATCH v2 nf] netfilter: nf_flow_table_ip: Introduce nf_flow_vlan_push()
From: Eric Woudstra @ 2026-04-14 12:00 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Florian Westphal, Phil Sutter, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, netfilter-devel,
netdev
In-Reply-To: <ad4nQzsbeF1S53zt@chamomile>
On 4/14/26 1:38 PM, Pablo Neira Ayuso wrote:
> On Tue, Apr 14, 2026 at 01:21:20PM +0200, Eric Woudstra wrote:
>> Calling skb_reset_mac_header() before calling skb_vlan_push() does
>> remove the error:
>>
>> "skb_vlan_push got skb with skb->data not at mac header (offset 18)"
>>
>> But the inner vlan tag is still not inserted correctly.
>>
>> skb_vlan_push() uses __vlan_insert_inner_tag() to insert the tag
>> at offset ETH_HLEN. But the inner tag should only be pushed, without
>> offset, similar to nf_flow_pppoe_push().
>
> It is doubled-tagged-vlan that is broken, right? I observed this once
> but I have been burdened into a few things.
That is correct, both q-in-q and q-in-ad (that may not be the correct
terms, but I think it is clear).
>> Fixes: c653d5a78f34 ("netfilter: flowtable: inline vlan encapsulation in xmit path")
>> Fixes: a3aca98aec9a ("netfilter: nf_flow_table_ip: reset mac header before vlan push")
>> Signed-off-by: Eric Woudstra <ericwouds@gmail.com>
>>
>> ---
>>
>> net/netfilter/nf_flow_table_ip.c | 25 ++++++++++++++++++++++---
>> 1 file changed, 22 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/netfilter/nf_flow_table_ip.c b/net/netfilter/nf_flow_table_ip.c
>> index fd56d663cb5b..0086f8a1a0d6 100644
>> --- a/net/netfilter/nf_flow_table_ip.c
>> +++ b/net/netfilter/nf_flow_table_ip.c
>> @@ -544,6 +544,26 @@ static int nf_flow_offload_forward(struct nf_flowtable_ctx *ctx,
>> return 1;
>> }
>>
>> +static int nf_flow_vlan_push(struct sk_buff *skb, __be16 proto, u16 id)
>> +{
>> + if (skb_vlan_tag_present(skb)) {
>> + struct vlan_hdr *vhdr;
>> +
>> + if (skb_cow_head(skb, VLAN_HLEN))
>> + return -1;
>> +
>> + __skb_push(skb, VLAN_HLEN);
>> + skb_reset_network_header(skb);
>> + vhdr = (struct vlan_hdr *)(skb->data);
>> + vhdr->h_vlan_TCI = htons(id);
>> + vhdr->h_vlan_encapsulated_proto = skb->protocol;
>> + skb->protocol = proto;
>> + } else {
>> + __vlan_hwaccel_put_tag(skb, proto, id);
>> + }
>> + return 0;
>> +}
>> +
>> static int nf_flow_pppoe_push(struct sk_buff *skb, u16 id)
>> {
>> int data_len = skb->len + sizeof(__be16);
>> @@ -738,9 +758,8 @@ static int nf_flow_encap_push(struct sk_buff *skb,
>> switch (tuple->encap[i].proto) {
>> case htons(ETH_P_8021Q):
>> case htons(ETH_P_8021AD):
>> - skb_reset_mac_header(skb);
>> - if (skb_vlan_push(skb, tuple->encap[i].proto,
>> - tuple->encap[i].id) < 0)
>> + if (nf_flow_vlan_push(skb, tuple->encap[i].proto,
>> + tuple->encap[i].id) < 0)
>> return -1;
>> break;
>> case htons(ETH_P_PPP_SES):
>> --
>> 2.53.0
>>
^ permalink raw reply
* Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Fidelio LAWSON @ 2026-04-14 11:59 UTC (permalink / raw)
To: Marek Vasut, Woojung Huh, UNGLinuxDriver, Andrew Lunn,
Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Marek Vasut, Maxime Chevallier, Simon Horman,
Heiner Kallweit, Russell King
Cc: netdev, linux-kernel, Fidelio Lawson
In-Reply-To: <ea90a671-70be-4d89-b842-1e54d687336f@nabladev.com>
On 4/14/26 13:05, 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 ?
You are right that EQ training and LPF bandwidth control
are orthogonal from a hardware point of view.
In this case, the interface is intentionally modeled after the erratum
guidance rather than exposing all possible combinations. Microchip
documents the workarounds as alternative solutions:
"If work around 1 does not solve the short cable issue in a CAT-5E or
CAT-6 application, change the work around 1 register (0x3C) to its
default value (0x0A), and use the following settings"
from:
https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/Errata/KSZ87xx-Errata-DS80000687C.pdf
If you’d prefer exposing these as orthogonal controls, I can revise the
interface in the next iteration.
^ permalink raw reply
* [syzbot] [bridge?] KASAN: use-after-free Read in qdisc_pkt_len_segs_init
From: syzbot @ 2026-04-14 11:58 UTC (permalink / raw)
To: bridge, davem, edumazet, horms, idosch, kuba, linux-kernel,
netdev, pabeni, razor, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 17ad4759a082 Merge branch 'wangxun-improvement'
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1505dcd2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=229411a0a13ccb7d
dashboard link: https://syzkaller.appspot.com/bug?extid=83181a31faf9455499c5
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/b67be09d914c/disk-17ad4759.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/20a2548795c3/vmlinux-17ad4759.xz
kernel image: https://storage.googleapis.com/syzbot-assets/29e723395cef/bzImage-17ad4759.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+83181a31faf9455499c5@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in __tcp_hdrlen include/linux/tcp.h:31 [inline]
BUG: KASAN: use-after-free in qdisc_pkt_len_segs_init+0x7f8/0xa30 net/core/dev.c:4146
Read of size 2 at addr ffff88815ace2434 by task syz.2.24/6033
CPU: 0 UID: 0 PID: 6033 Comm: syz.2.24 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Call Trace:
<IRQ>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xba/0x230 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
__tcp_hdrlen include/linux/tcp.h:31 [inline]
qdisc_pkt_len_segs_init+0x7f8/0xa30 net/core/dev.c:4146
sch_handle_ingress net/core/dev.c:4483 [inline]
__netif_receive_skb_core+0x13bd/0x31a0 net/core/dev.c:6065
__netif_receive_skb_list_core+0x24d/0x810 net/core/dev.c:6289
__netif_receive_skb_list net/core/dev.c:6356 [inline]
netif_receive_skb_list_internal+0x995/0xcf0 net/core/dev.c:6447
gro_normal_list include/net/gro.h:523 [inline]
gro_flush_normal include/net/gro.h:531 [inline]
napi_complete_done+0x299/0x730 net/core/dev.c:6815
gro_cell_poll+0x5a9/0x5d0 net/core/gro_cells.c:74
__napi_poll+0xae/0x340 net/core/dev.c:7742
napi_poll net/core/dev.c:7805 [inline]
net_rx_action+0x627/0xf70 net/core/dev.c:7962
handle_softirqs+0x22a/0x870 kernel/softirq.c:622
do_softirq+0x76/0xd0 kernel/softirq.c:523
</IRQ>
<TASK>
__local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450
local_bh_enable include/linux/bottom_half.h:33 [inline]
tun_rx_batched+0x617/0x790 drivers/net/tun.c:-1
tun_get_user+0x2aeb/0x3ed0 drivers/net/tun.c:1953
tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1999
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x61d/0xb90 fs/read_write.c:688
ksys_write+0x150/0x270 fs/read_write.c:740
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f177e39c819
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f177f1e3028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f177e616180 RCX: 00007f177e39c819
RDX: 000000000000fdef RSI: 00002000000002c0 RDI: 0000000000000003
RBP: 00007f177e432c91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f177e616218 R14: 00007f177e616180 R15: 00007ffee7d40588
</TASK>
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x15ace2
flags: 0x57ff00000000000(node=1|zone=2|lastcpupid=0x7ff)
raw: 057ff00000000000 ffffea00056b3888 ffffea00056b3888 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner info is not present (never set?)
Memory state around the buggy address:
ffff88815ace2300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88815ace2380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff88815ace2400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff88815ace2480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88815ace2500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: Jesper Dangaard Brouer @ 2026-04-14 11:56 UTC (permalink / raw)
To: Mark Brown, David Miller, Jakub Kicinski, Paolo Abeni, Networking
Cc: Fernando Fernandez Mancera, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <adz0iX85FHMz0HdO@sirena.org.uk>
On 13/04/2026 15.50, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> include/net/sch_generic.h
>
> between commit:
>
> a6bd339dbb351 ("net_sched: fix skb memory leak in deferred qdisc drops")
>
> from the net tree and commit:
>
> ff2998f29f390 ("net: sched: introduce qdisc-specific drop reason tracing")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc include/net/sch_generic.h
> index 5fc0b1ebaf25c,5af262ec4bbd2..0000000000000
> --- a/include/net/sch_generic.h
> +++ b/include/net/sch_generic.h
> @@@ -1168,24 -1185,14 +1185,24 @@@ static inline void tcf_kfree_skb_list(s
> }
>
> static inline void qdisc_dequeue_drop(struct Qdisc *q, struct sk_buff *skb,
> - enum skb_drop_reason reason)
> + enum qdisc_drop_reason reason)
> {
> + struct Qdisc *root;
> +
> DEBUG_NET_WARN_ON_ONCE(!(q->flags & TCQ_F_DEQUEUE_DROPS));
> DEBUG_NET_WARN_ON_ONCE(q->flags & TCQ_F_NOLOCK);
>
> - tcf_set_qdisc_drop_reason(skb, reason);
> - skb->next = q->to_free;
> - q->to_free = skb;
> + rcu_read_lock();
> + root = qdisc_root_sleeping(q);
> +
> + if (root->flags & TCQ_F_DEQUEUE_DROPS) {
> - tcf_set_drop_reason(skb, reason);
> ++ tcf_set_qdisc_drop_reason(skb, reason);
Change/merge looks sane to me :-)
--Jesper
> + skb->next = root->to_free;
> + root->to_free = skb;
> + } else {
> + kfree_skb_reason(skb, (enum skb_drop_reason)reason);
> + }
> + rcu_read_unlock();
> }
>
> /* Instead of calling kfree_skb() while root qdisc lock is held,
^ permalink raw reply
* Re: [PATCH v2] netfilter: nfnetlink_osf: fix null-ptr-deref in nf_osf_ttl
From: Fernando Fernandez Mancera @ 2026-04-14 11:50 UTC (permalink / raw)
To: Kito Xu (veritas501), pablo
Cc: coreteam, davem, edumazet, ffmancera, fw, horms, kuba,
linux-kernel, netdev, netfilter-devel, pabeni, phil
In-Reply-To: <20260414104900.2617863-1-hxzene@gmail.com>
On 4/14/26 12:49 PM, Kito Xu (veritas501) wrote:
> nf_osf_ttl() calls __in_dev_get_rcu(skb->dev) and passes the result
> to in_dev_for_each_ifa_rcu() without checking for NULL. When the
> receiving device has no IPv4 configuration (ip_ptr is NULL),
> __in_dev_get_rcu() returns NULL and in_dev_for_each_ifa_rcu()
> dereferences it unconditionally, causing a kernel crash.
>
> This can happen when a packet arrives on a device that has had its
> IPv4 configuration removed (e.g., MTU set below IPV4_MIN_MTU causing
> inetdev_destroy) or on a device that was never assigned an IPv4
> address, while an xt_osf or nft_osf rule with TTL_LESS mode is
> active and the packet TTL exceeds the fingerprint TTL.
>
> Add a NULL check for in_dev before using it. When in_dev is NULL,
> return 0 (no match) since source-address locality cannot be
> determined without IPv4 addresses on the device.
>
> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
> RIP: 0010:nf_osf_match_one+0x204/0xa70
> Call Trace:
> <IRQ>
> nf_osf_match+0x2f8/0x780
> xt_osf_match_packet+0x11c/0x1f0
> ipt_do_table+0x7fe/0x12b0
> nf_hook_slow+0xac/0x1e0
> ip_rcv+0x123/0x370
> __netif_receive_skb_one_core+0x166/0x1b0
> process_backlog+0x197/0x590
> __napi_poll+0xa1/0x540
> net_rx_action+0x401/0xd80
> handle_softirqs+0x19f/0x610
> </IRQ>
>
> Fixes: a218dc82f0b5 ("netfilter: nft_osf: Add ttl option support")
> Suggested-by: Pablo Neira Ayuso <pablo@netfilter.org>
> Signed-off-by: Kito Xu (veritas501) <hxzene@gmail.com>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Thanks !
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 0/3] i40e: support XDP metadata ops (RX
From: Holda, Patryk @ 2026-04-14 11:46 UTC (permalink / raw)
To: Joe Damato, Kohei Enju
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
Nguyen, Anthony L, Kitszel, Przemyslaw, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
kohei.enju@gmail.com
In-Reply-To: <ab3TtpEKY5Pg+uQt@devvm20253.cco0.facebook.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Joe Damato
> Sent: Saturday, March 21, 2026 12:10 AM
> To: Kohei Enju <kohei@enjuk.jp>
> Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; 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 0/3] i40e: support XDP
> metadata ops (RX
>
> On Thu, Mar 19, 2026 at 05:16:41PM +0000, Kohei Enju wrote:
> > This series adds support for XDP metadata ops. Since the i40e RX
> > timestamps are not available from the RX descriptor in the XDP path,
> > this series doesn't implement bpf_xdp_metadata_rx_timestamp().
> >
> > Patch 1/3 prepares i40e_xdp_buff for subsequent patches.
> > Patch 2/3 and 3/3 introduce bpf_xdp_metadata_rx_hash() and
> > bpf_xdp_metadata_rx_vlan_tag() respectively.
> >
> > Tested on Intel Corporation Ethernet Controller X710 for 10GbE SFP+
> > with ./tools/testing/selftests/bpf/xdp_hw_metadata.
> > Since i40e doesn't support HWTSTAMP_FILTER_ALL as an rx_filter, I
> > locally changed the selftest to use HWTSTAMP_FILTER_NONE instead.
> >
> > Kohei Enju (3):
> > i40e: prepare for XDP metadata ops support
> > i40e: add support for bpf_xdp_metadata_rx_hash()
> > i40e: add support for bpf_xdp_metadata_rx_vlan_tag()
> >
> > drivers/net/ethernet/intel/i40e/i40e_main.c | 51
> > ++++++++++++++++++++- drivers/net/ethernet/intel/i40e/i40e_txrx.c |
> > 5 +- drivers/net/ethernet/intel/i40e/i40e_txrx.h | 7 ++-
> > drivers/net/ethernet/intel/i40e/i40e_type.h | 5 ++
> > drivers/net/ethernet/intel/i40e/i40e_xsk.c | 12 +++++
> > 5 files changed, 77 insertions(+), 3 deletions(-)
>
> For the series:
>
> Reviewed-by: Joe Damato <joe@dama.to>
Tested-by: Patryk Holda <patryk.holda@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 3/3] i40e: add support for bpf_xdp_metadata_rx_vlan_tag()
From: Holda, Patryk @ 2026-04-14 11:46 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: <IA3PR11MB89865073DDFC1987A6445DA7E54CA@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:58 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 3/3] i40e: add support for
> bpf_xdp_metadata_rx_vlan_tag()
>
>
>
> > -----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 3/3] i40e: add support
> > for bpf_xdp_metadata_rx_vlan_tag()
> >
> > Introduce i40e_xdp_rx_vlan_tag() which takes the same approach as
> > i40e_process_skb_fields() to extract the VLAN tag from the RX
> > descriptor.
> >
> > Tested with X710 adapter using xdp_hw_metadata, and confirmed that
> > VLAN tags match between bpf_xdp_metadata_rx_vlan_tag() and
> > skb->vlan_proto/vlan_tci.
> >
> > Signed-off-by: Kohei Enju <kohei@enjuk.jp>
> > ---
> > drivers/net/ethernet/intel/i40e/i40e_main.c | 19 +++++++++++++++++++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> > b/drivers/net/ethernet/intel/i40e/i40e_main.c
> > index 6b7e34b16a8d..3749f32ef95a 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> > @@ -13610,8 +13610,27 @@ static int i40e_xdp_rx_hash(const struct
> > xdp_md *_ctx, u32 *hash,
> > return 0;
> > }
> >
> > +static int i40e_xdp_rx_vlan_tag(const struct xdp_md *_ctx, __be16
> > *vlan_proto,
> > + u16 *vlan_tci)
> > +{
> > + const struct i40e_xdp_buff *ctx = (const void *)_ctx;
> > + const union i40e_rx_desc *desc = ctx->desc;
> > + u64 status;
> > +
> > + status = le64_to_cpu(desc->wb.qword1.status_error_len);
> > +
> > + if (!(status & BIT(I40E_RX_DESC_STATUS_L2TAG1P_SHIFT)))
> > + return -ENODATA;
> > +
> > + *vlan_proto = cpu_to_be16(ETH_P_8021Q);
> > + *vlan_tci = le16_to_cpu(desc->wb.qword0.lo_dword.l2tag1);
> > +
> > + return 0;
> > +}
> > +
> > static const struct xdp_metadata_ops i40e_xdp_metadata_ops = {
> > .xmo_rx_hash = i40e_xdp_rx_hash,
> > + .xmo_rx_vlan_tag = i40e_xdp_rx_vlan_tag,
> > };
> >
> > static const struct net_device_ops i40e_netdev_ops = {
> > --
> > 2.51.0
>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Patryk Holda <patryk.holda@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 2/3] i40e: add support for bpf_xdp_metadata_rx_hash()
From: Holda, Patryk @ 2026-04-14 11:45 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: <IA3PR11MB8986D3E4DF65EC87E23A6C1BE54CA@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 2/3] i40e: add support for
> bpf_xdp_metadata_rx_hash()
>
>
>
> > -----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 2/3] i40e: add support
> > for bpf_xdp_metadata_rx_hash()
> >
> > Introduce i40e_xdp_rx_hash() which takes the same approach as
> > i40e_rx_hash() to extract the hash from RX descriptors.
> >
> > Tested with X710 adapter using xdp_hw_metadata, and verified hash
> > consistency between bpf_xdp_metadata_rx_hash() and skb->hash.
> >
> > Signed-off-by: Kohei Enju <kohei@enjuk.jp>
> > ---
> > drivers/net/ethernet/intel/i40e/i40e_main.c | 30
> > +++++++++++++++++++++ drivers/net/ethernet/intel/i40e/i40e_type.h |
> > 5 ++++
> > 2 files changed, 35 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> > b/drivers/net/ethernet/intel/i40e/i40e_main.c
> > index 7966d9cb8009..6b7e34b16a8d 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> > @@ -4,6 +4,7 @@
> > #include <generated/utsrelease.h>
> > #include <linux/crash_dump.h>
> > #include <linux/intel/libie/pctype.h>
> > +#include <linux/intel/libie/rx.h>
> > #include <linux/if_bridge.h>
> > #include <linux/if_macvlan.h>
> > #include <linux/module.h>
> > @@ -13585,6 +13586,34 @@ static int i40e_xdp(struct net_device *dev,
> > }
> > }
> >
> > +static int i40e_xdp_rx_hash(const struct xdp_md *_ctx, u32 *hash,
> > + enum xdp_rss_hash_type *rss_type) {
> > + const struct i40e_xdp_buff *ctx = (const void *)_ctx;
> > + const union i40e_rx_desc *desc = ctx->desc;
> > + struct libeth_rx_pt rx_ptype;
> > + u8 raw_rx_ptype;
> > + u64 status;
> > +
> > + status = le64_to_cpu(desc->wb.qword1.status_error_len);
> > + raw_rx_ptype = FIELD_GET(I40E_RXD_QW1_PTYPE_MASK, status);
> > + rx_ptype = libie_rx_pt_parse(raw_rx_ptype);
> > +
> > + if (!libeth_rx_pt_has_hash(ctx->xdp.rxq->dev, rx_ptype) ||
> > + FIELD_GET(I40E_RX_DESC_STATUS_FLTSTAT_MASK, status) !=
> > + I40E_RX_DESC_FLTSTAT_RSS_HASH)
> > + return -ENODATA;
> > +
> > + *hash = le32_to_cpu(desc->wb.qword0.hi_dword.rss);
> > + *rss_type = rx_ptype.hash_type;
> > +
> > + return 0;
> > +}
> > +
> > +static const struct xdp_metadata_ops i40e_xdp_metadata_ops = {
> > + .xmo_rx_hash = i40e_xdp_rx_hash,
> > +};
> > +
> > static const struct net_device_ops i40e_netdev_ops = {
> > .ndo_open = i40e_open,
> > .ndo_stop = i40e_close,
> > @@ -13788,6 +13817,7 @@ static int i40e_config_netdev(struct i40e_vsi
> > *vsi)
> > i40e_vsi_config_netdev_tc(vsi, vsi->tc_config.enabled_tc);
> >
> > netdev->netdev_ops = &i40e_netdev_ops;
> > + netdev->xdp_metadata_ops = &i40e_xdp_metadata_ops;
> > netdev->watchdog_timeo = 5 * HZ;
> > i40e_set_ethtool_ops(netdev);
> >
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_type.h
> > b/drivers/net/ethernet/intel/i40e/i40e_type.h
> > index ed8bbdb586da..16a65c6e5153 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_type.h
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_type.h
> > @@ -4,6 +4,7 @@
> > #ifndef _I40E_TYPE_H_
> > #define _I40E_TYPE_H_
> >
> > +#include <linux/bits.h>
> > #include <uapi/linux/if_ether.h>
> > #include "i40e_adminq.h"
> > #include "i40e_hmc.h"
> > @@ -699,6 +700,10 @@ enum i40e_rx_desc_status_bits {
> > I40E_RX_DESC_STATUS_LAST /* this entry must be last!!! */ };
> >
> > +#define I40E_RX_DESC_STATUS_FLTSTAT_MASK \
> > + GENMASK_ULL(I40E_RX_DESC_STATUS_FLTSTAT_SHIFT + 1, \
> > + I40E_RX_DESC_STATUS_FLTSTAT_SHIFT)
> > +
> > #define I40E_RXD_QW1_STATUS_SHIFT 0
> > #define I40E_RXD_QW1_STATUS_MASK
> ((BIT(I40E_RX_DESC_STATUS_LAST) - 1)
> > \
> > << I40E_RXD_QW1_STATUS_SHIFT)
> > --
> > 2.51.0
>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Patryk Holda <patryk.holda@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v4] ice: remove excessive memory allocation in ice_create_lag_recipe()
From: Holda, Patryk @ 2026-04-14 11:45 UTC (permalink / raw)
To: Loktionov, Aleksandr, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L, Loktionov, Aleksandr
Cc: netdev@vger.kernel.org, Szycik, Marcin, Joe Damato
In-Reply-To: <20260327064855.112786-1-aleksandr.loktionov@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Aleksandr Loktionov
> Sent: Friday, March 27, 2026 7:49 AM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>
> Cc: netdev@vger.kernel.org; Szycik, Marcin <marcin.szycik@intel.com>; Joe
> Damato <joe@dama.to>
> Subject: [Intel-wired-lan] [PATCH iwl-next v4] ice: remove excessive memory
> allocation in ice_create_lag_recipe()
>
> From: Marcin Szycik <marcin.szycik@intel.com>
>
> For some reason ice_create_lag_recipe() allocates an array of 64 struct
> ice_aqc_recipe_data_elem elements, while it only needs one (1).
> Fix it, while also using kzalloc_obj().
>
> Signed-off-by: Marcin Szycik <marcin.szycik@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Reviewed-by: Joe Damato <joe@dama.to>
> ---
> v3 -> v4 corrected misspeled RB from Joe
> v2 -> v3 use sizeof(*new_rcp) in memcpy() to match the allocation (Joe)
> v1 -> v2 remove 'Fixes' from commit message because it's not a critical bug
> ---
> drivers/net/ethernet/intel/ice/ice_lag.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_lag.c
> b/drivers/net/ethernet/intel/ice/ice_lag.c
> index 310e8fe..9ad19c3 100644
> --- a/drivers/net/ethernet/intel/ice/ice_lag.c
> +++ b/drivers/net/ethernet/intel/ice/ice_lag.c
> @@ -2418,11 +2418,11 @@ static int ice_create_lag_recipe(struct ice_hw
> *hw, u16 *rid,
> if (err)
> return err;
>
> - new_rcp = kzalloc(ICE_RECIPE_LEN * ICE_MAX_NUM_RECIPES,
> GFP_KERNEL);
> + new_rcp = kzalloc_obj(*new_rcp, GFP_KERNEL);
> if (!new_rcp)
> return -ENOMEM;
>
> - memcpy(new_rcp, base_recipe, ICE_RECIPE_LEN);
> + memcpy(new_rcp, base_recipe, sizeof(*new_rcp));
> new_rcp->content.act_ctrl_fwd_priority = prio;
> new_rcp->content.rid = *rid | ICE_AQ_RECIPE_ID_IS_ROOT;
> new_rcp->recipe_indx = *rid;
Tested-by: Patryk Holda <patryk.holda@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v2] ice: call netif_keep_dst() once when entering switchdev mode
From: Holda, Patryk @ 2026-04-14 11:44 UTC (permalink / raw)
To: Paul Menzel, Loktionov, Aleksandr
Cc: intel-wired-lan@lists.osuosl.org, Nguyen, Anthony L,
netdev@vger.kernel.org, Szycik, Marcin
In-Reply-To: <d87f554d-ef86-44c7-9585-0a3806cc5752@molgen.mpg.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Paul Menzel
> Sent: Wednesday, April 8, 2026 4:28 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 v2] ice: call netif_keep_dst()
> once when entering switchdev mode
>
> Dear Aleksandr, dear Marcin,
>
>
> Thank you for the patch.
>
> Am 08.04.26 um 16:14 schrieb Aleksandr Loktionov:
> > 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().
>
> It’d be great, if you could share the commands, how to verify your change.
>
> > Fixes: defd52455aee ("ice: do Tx through PF netdev in slow-path")
> > Signed-off-by: Marcin Szycik <marcin.szycik@intel.com>
> > Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> > ---
> > v1 -> v2:
> > - Verified Fixes: tag via bisect - defd52455aee introduced the redundant
> > per-repr call to netif_keep_dst(uplink_vsi->netdev) by changing the
> > target netdev to the uplink VSI inside the per-representor setup
> > function. Before that commit, each call was on a distinct repr->netdev
> > so no Fixes: predating it applies.
> >
> > drivers/net/ethernet/intel/ice/ice_eswitch.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/ice/ice_eswitch.c
> > b/drivers/net/ethernet/intel/ice/ice_eswitch.c
> > index 2e4f096..c30e27b 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_eswitch.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_eswitch.c
> > @@ -117,8 +117,6 @@ static int ice_eswitch_setup_repr(struct ice_pf
> *pf, struct ice_repr *repr)
> > if (!repr->dst)
> > return -ENOMEM;
> >
> > - netif_keep_dst(uplink_vsi->netdev);
> > -
> > dst = repr->dst;
> > dst->u.port_info.port_id = vsi->vsi_num;
> > dst->u.port_info.lower_dev = uplink_vsi->netdev; @@ -312,6 +310,8
> > @@ static int ice_eswitch_enable_switchdev(struct ice_pf *pf)
> > if (ice_eswitch_br_offloads_init(pf))
> > goto err_br_offloads;
> >
> > + netif_keep_dst(uplink_vsi->netdev);
> > +
> > pf->eswitch.is_running = true;
> >
> > return 0;
>
> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
>
>
> Kind regards,
>
> Paul
Tested-by: Patryk Holda <patryk.holda@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net v3 5/5] iavf: refactor virtchnl polling into single function
From: Loktionov, Aleksandr @ 2026-04-14 11:43 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, netdev@vger.kernel.org
Cc: intel-wired-lan@lists.osuosl.org, jesse.brandeburg@intel.com,
Nguyen, Anthony L, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, Kitszel, Przemyslaw
In-Reply-To: <20260414110006.124286-6-jtornosm@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Jose Ignacio Tornos Martinez
> Sent: Tuesday, April 14, 2026 1:00 PM
> To: netdev@vger.kernel.org
> Cc: intel-wired-lan@lists.osuosl.org; jesse.brandeburg@intel.com;
> Nguyen, Anthony L <anthony.l.nguyen@intel.com>; davem@davemloft.net;
> edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; Jose Ignacio
> Tornos Martinez <jtornosm@redhat.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>
> Subject: [Intel-wired-lan] [PATCH net v3 5/5] iavf: refactor virtchnl
> polling into single function
For me it looks it should go to net-next as a refactoring.
>
> At this moment, the driver has two separate functions for polling
> virtchnl messages from the admin queue:
> - iavf_poll_virtchnl_msg() for init-time (no timeout, no completion
> handler)
> - iavf_poll_virtchnl_response() for runtime (with timeout, calls
> completion)
>
> Refactor by enhancing iavf_poll_virtchnl_msg() to handle both use
> cases:
> 1. Init-time mode (timeout_ms=0):
> - Polls until matching opcode found or queue empty
> - Returns raw message data without processing through completion
> handler
> - Exits immediately on empty queue (no sleep/retry) 2. Runtime mode
> (timeout_ms>0):
> - Polls with timeout using condition callback or opcode check
> - Processes all messages through iavf_virtchnl_completion()
> - Supports custom completion callback (takes priority) or falls back
> to checking adapter->current_op against expected opcode
> - Uses pending parameter to skip sleep when more messages queued
> - Uses 50-75 usec sleep (due to commit 9e3f23f44f32 ("i40e: reduce
> wait
> time for adminq command completion"))
>
> By unifying message handling, both init-time and runtime messages can
> be processed through the completion handler when appropriate, ensuring
> consistent state updates and maintaining backward compatibility with
> all existing call sites.
>
> Suggested-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> ---
> drivers/net/ethernet/intel/iavf/iavf.h | 9 +-
> drivers/net/ethernet/intel/iavf/iavf_main.c | 13 +-
> .../net/ethernet/intel/iavf/iavf_virtchnl.c | 247 ++++++++---------
...
> --
> 2.53.0
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net v2 4/4] ice: skip unnecessary VF reset when setting trust
From: Loktionov, Aleksandr @ 2026-04-14 11:41 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, netdev@vger.kernel.org
Cc: intel-wired-lan@lists.osuosl.org, jesse.brandeburg@intel.com,
Nguyen, Anthony L, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com
In-Reply-To: <20260407165206.1121317-5-jtornosm@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Jose Ignacio Tornos Martinez
> Sent: Tuesday, April 7, 2026 6:52 PM
> To: netdev@vger.kernel.org
> Cc: intel-wired-lan@lists.osuosl.org; jesse.brandeburg@intel.com;
> Nguyen, Anthony L <anthony.l.nguyen@intel.com>; davem@davemloft.net;
> edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; Jose Ignacio
> Tornos Martinez <jtornosm@redhat.com>
> Subject: [Intel-wired-lan] [PATCH net v2 4/4] ice: skip unnecessary VF
> reset when setting trust
>
> Similar to the i40e fix, ice_set_vf_trust() unconditionally calls
> ice_reset_vf() when the trust setting changes.
>
> The ice driver already has logic to clean up MAC LLDP filters when
> removing trust, which is the only operation that requires filter
> synchronization. After this cleanup, the VF reset is only necessary if
> there were actually filters to remove.
>
> For all other trust state changes (setting trust, or removing trust
> when no filters exist), the reset is unnecessary as filter
> synchronization happens naturally through normal VF operations.
>
> Fix by only triggering the VF reset when removing trust AND filters
> were actually cleaned up (num_mac_lldp was non-zero).
>
> This saves some time and eliminates unnecessary service disruption
> when changing VF trust settings if not necessary.
>
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> ---
> drivers/net/ethernet/intel/ice/ice_sriov.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c
> b/drivers/net/ethernet/intel/ice/ice_sriov.c
> index 7e00e091756d..23f692b1e86c 100644
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
> @@ -1399,14 +1399,19 @@ int ice_set_vf_trust(struct net_device
> *netdev, int vf_id, bool trusted)
>
> mutex_lock(&vf->cfg_lock);
>
> - while (!trusted && vf->num_mac_lldp)
> - ice_vf_update_mac_lldp_num(vf, ice_get_vf_vsi(vf),
> false);
> -
> vf->trusted = trusted;
> - ice_reset_vf(vf, ICE_VF_RESET_NOTIFY);
> dev_info(ice_pf_to_dev(pf), "VF %u is now %strusted\n",
> vf_id, trusted ? "" : "un");
>
> + /* Only reset VF if removing trust and there are MAC LLDP
> filters
> + * to clean up. Reset is needed to ensure filter removal
> completes.
> + */
> + if (!trusted && vf->num_mac_lldp) {
> + while (vf->num_mac_lldp)
> + ice_vf_update_mac_lldp_num(vf,
> ice_get_vf_vsi(vf), false);
> + ice_reset_vf(vf, ICE_VF_RESET_NOTIFY);
> + }
> +
> mutex_unlock(&vf->cfg_lock);
>
> out_put_vf:
> --
> 2.53.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net v3 2/5] i40e: skip unnecessary VF reset when setting trust
From: Loktionov, Aleksandr @ 2026-04-14 11:41 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, netdev@vger.kernel.org
Cc: intel-wired-lan@lists.osuosl.org, jesse.brandeburg@intel.com,
Nguyen, Anthony L, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com
In-Reply-To: <20260414110006.124286-3-jtornosm@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Jose Ignacio Tornos Martinez
> Sent: Tuesday, April 14, 2026 1:00 PM
> To: netdev@vger.kernel.org
> Cc: intel-wired-lan@lists.osuosl.org; jesse.brandeburg@intel.com;
> Nguyen, Anthony L <anthony.l.nguyen@intel.com>; davem@davemloft.net;
> edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; Jose Ignacio
> Tornos Martinez <jtornosm@redhat.com>
> Subject: [Intel-wired-lan] [PATCH net v3 2/5] i40e: skip unnecessary
> VF reset when setting trust
>
> When VF trust is changed, i40e_ndo_set_vf_trust() always calls
> i40e_vc_reset_vf() to sync MAC/VLAN filters. However, this reset is
> only necessary when trust is removed from a VF that has ADQ (advanced
> queue) filters, which need to be deleted
>
> In all other cases, the reset causes a ~10 second delay during which:
> - VF must reinitialize completely
> - Any in-progress operations (like bonding enslave) fail with timeouts
> - VF is unavailable
>
> The MAC/VLAN filter sync will happen naturally through the normal VF
> operations and doesn't require a forced reset.
>
> Fix by only resetting when actually needed: when removing trust from a
> VF that has ADQ cloud filters. For all other trust changes, just
> update the trust flag and let normal operation continue.
>
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> index a26c3d47ec15..fea267af7afe 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> @@ -4987,16 +4987,21 @@ int i40e_ndo_set_vf_trust(struct net_device
> *netdev, int vf_id, bool setting)
> set_bit(__I40E_MACVLAN_SYNC_PENDING, pf->state);
> pf->vsi[vf->lan_vsi_idx]->flags |=
> I40E_VSI_FLAG_FILTER_CHANGED;
>
> - i40e_vc_reset_vf(vf, true);
> dev_info(&pf->pdev->dev, "VF %u is now %strusted\n",
> vf_id, setting ? "" : "un");
>
> + /* Only reset VF if we're removing trust and it has ADQ cloud
> filters.
> + * Cloud filters can only be added when trusted, so they must
> be
> + * removed when trust is revoked. Other trust changes don't
> require
> + * reset - MAC/VLAN filter sync happens through normal
> operation.
> + */
> if (vf->adq_enabled) {
> if (!vf->trusted) {
> dev_info(&pf->pdev->dev,
> "VF %u no longer Trusted, deleting all
> cloud filters\n",
> vf_id);
> i40e_del_all_cloud_filters(vf);
> + i40e_vc_reset_vf(vf, true);
> }
> }
>
> --
> 2.53.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix VIP configuration for AN7583 SoC
From: patchwork-bot+netdevbpf @ 2026-04-14 11:40 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260412-airoha-7583-vip-fix-v1-1-c35e02b054bb@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sun, 12 Apr 2026 09:57:29 +0200 you wrote:
> EN7581 and AN7583 SoCs have different VIP definitions. Introduce
> get_vip_port callback in airoha_eth_soc_data struct in order to take
> into account EN7581 and AN7583 VIP register layout and definition
> differences.
> Introduce nbq parameter in airoha_gdm_port struct. At the moment nbq
> is set statically to value previously used in airhoha_set_gdm2_loopback
> routine and it will be read from device tree in subsequent patches.
>
> [...]
Here is the summary with links:
- [net] net: airoha: Fix VIP configuration for AN7583 SoC
https://git.kernel.org/netdev/net/c/1acdfbdb516b
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 v2 nf] netfilter: nf_flow_table_ip: Introduce nf_flow_vlan_push()
From: Pablo Neira Ayuso @ 2026-04-14 11:38 UTC (permalink / raw)
To: Eric Woudstra
Cc: Florian Westphal, Phil Sutter, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, netfilter-devel,
netdev
In-Reply-To: <20260414112120.248744-1-ericwouds@gmail.com>
On Tue, Apr 14, 2026 at 01:21:20PM +0200, Eric Woudstra wrote:
> Calling skb_reset_mac_header() before calling skb_vlan_push() does
> remove the error:
>
> "skb_vlan_push got skb with skb->data not at mac header (offset 18)"
>
> But the inner vlan tag is still not inserted correctly.
>
> skb_vlan_push() uses __vlan_insert_inner_tag() to insert the tag
> at offset ETH_HLEN. But the inner tag should only be pushed, without
> offset, similar to nf_flow_pppoe_push().
It is doubled-tagged-vlan that is broken, right? I observed this once
but I have been burdened into a few things.
> Fixes: c653d5a78f34 ("netfilter: flowtable: inline vlan encapsulation in xmit path")
> Fixes: a3aca98aec9a ("netfilter: nf_flow_table_ip: reset mac header before vlan push")
> Signed-off-by: Eric Woudstra <ericwouds@gmail.com>
>
> ---
>
> net/netfilter/nf_flow_table_ip.c | 25 ++++++++++++++++++++++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/net/netfilter/nf_flow_table_ip.c b/net/netfilter/nf_flow_table_ip.c
> index fd56d663cb5b..0086f8a1a0d6 100644
> --- a/net/netfilter/nf_flow_table_ip.c
> +++ b/net/netfilter/nf_flow_table_ip.c
> @@ -544,6 +544,26 @@ static int nf_flow_offload_forward(struct nf_flowtable_ctx *ctx,
> return 1;
> }
>
> +static int nf_flow_vlan_push(struct sk_buff *skb, __be16 proto, u16 id)
> +{
> + if (skb_vlan_tag_present(skb)) {
> + struct vlan_hdr *vhdr;
> +
> + if (skb_cow_head(skb, VLAN_HLEN))
> + return -1;
> +
> + __skb_push(skb, VLAN_HLEN);
> + skb_reset_network_header(skb);
> + vhdr = (struct vlan_hdr *)(skb->data);
> + vhdr->h_vlan_TCI = htons(id);
> + vhdr->h_vlan_encapsulated_proto = skb->protocol;
> + skb->protocol = proto;
> + } else {
> + __vlan_hwaccel_put_tag(skb, proto, id);
> + }
> + return 0;
> +}
> +
> static int nf_flow_pppoe_push(struct sk_buff *skb, u16 id)
> {
> int data_len = skb->len + sizeof(__be16);
> @@ -738,9 +758,8 @@ static int nf_flow_encap_push(struct sk_buff *skb,
> switch (tuple->encap[i].proto) {
> case htons(ETH_P_8021Q):
> case htons(ETH_P_8021AD):
> - skb_reset_mac_header(skb);
> - if (skb_vlan_push(skb, tuple->encap[i].proto,
> - tuple->encap[i].id) < 0)
> + if (nf_flow_vlan_push(skb, tuple->encap[i].proto,
> + tuple->encap[i].id) < 0)
> return -1;
> break;
> case htons(ETH_P_PPP_SES):
> --
> 2.53.0
>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net 1/2] idpf: do not enable XDP if queue based scheduling is not supported
From: Holda, Patryk @ 2026-04-14 11:37 UTC (permalink / raw)
To: Hay, Joshua A, intel-wired-lan@lists.osuosl.org; +Cc: netdev@vger.kernel.org
In-Reply-To: <20260406233236.3585504-2-joshua.a.hay@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Joshua Hay
> Sent: Tuesday, April 7, 2026 1:33 AM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH iwl-net 1/2] idpf: do not enable XDP if
> queue based scheduling is not supported
>
> The current XDP implementation uses queue based scheduling for its TxQs.
> If the FW does not advertise support for queue based scheduling, do not
> enable XDP. Add the missing capability check at the start of the XDP
> configuration. This will temporarily break XDP while a flow based
> implementation is worked on, as well as while FWs with queue based by
> default are rolled out.
>
> Fixes: 705457e7211f ("idpf: implement XDP_SETUP_PROG in ndo_bpf for
> splitq")
> Signed-off-by: Joshua Hay <joshua.a.hay@intel.com>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Reviewed-by: Madhu Chittim <madhu.chittim@intel.com>
> ---
> drivers/net/ethernet/intel/idpf/xdp.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/idpf/xdp.c
> b/drivers/net/ethernet/intel/idpf/xdp.c
> index 18a6e7062863..9c3bdb193684 100644
> --- a/drivers/net/ethernet/intel/idpf/xdp.c
> +++ b/drivers/net/ethernet/intel/idpf/xdp.c
> @@ -511,6 +511,13 @@ int idpf_xdp(struct net_device *dev, struct
> netdev_bpf *xdp)
> if (!idpf_is_queue_model_split(vport->dflt_qv_rsrc.txq_model))
> goto notsupp;
>
> + if (!idpf_is_cap_ena(vport->adapter, IDPF_OTHER_CAPS,
> + VIRTCHNL2_CAP_SPLITQ_QSCHED)) {
> + NL_SET_ERR_MSG_MOD(xdp->extack,
> + "Device does not support requested XDP Tx
> scheduling mode");
> + goto notsupp;
> + }
> +
> switch (xdp->command) {
> case XDP_SETUP_PROG:
> ret = idpf_xdp_setup_prog(vport, xdp);
> --
> 2.39.2
Tested-by: Patryk Holda <patryk.holda@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net v2] idpf: fix xdp crash in soft reset error path
From: Holda, Patryk @ 2026-04-14 11:36 UTC (permalink / raw)
To: Simon Horman, Tantilov, Emil S
Cc: daniel@iogearbox.net, ast@kernel.org, willemb@google.com,
stable@vger.kernel.org, decot@google.com, bpf@vger.kernel.org,
Nguyen, Anthony L, Kitszel, Przemyslaw,
intel-wired-lan@lists.osuosl.org, edumazet@google.com,
netdev@vger.kernel.org, pabeni@redhat.com, andrew+netdev@lunn.ch,
kuba@kernel.org, davem@davemloft.net, sdf@fomichev.me,
Loktionov, Aleksandr, Lobakin, Aleksander,
john.fastabend@gmail.com, hawk@kernel.org
In-Reply-To: <20260321091753.GT74886@horms.kernel.org>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Simon Horman
> Sent: Saturday, March 21, 2026 10:18 AM
> To: Tantilov, Emil S <emil.s.tantilov@intel.com>
> Cc: daniel@iogearbox.net; ast@kernel.org; willemb@google.com;
> stable@vger.kernel.org; decot@google.com; bpf@vger.kernel.org; Nguyen,
> Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; intel-wired-lan@lists.osuosl.org;
> edumazet@google.com; netdev@vger.kernel.org; pabeni@redhat.com;
> andrew+netdev@lunn.ch; kuba@kernel.org; davem@davemloft.net;
> sdf@fomichev.me; Loktionov, Aleksandr <aleksandr.loktionov@intel.com>;
> Lobakin, Aleksander <aleksander.lobakin@intel.com>;
> john.fastabend@gmail.com; hawk@kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH iwl-net v2] idpf: fix xdp crash in soft
> reset error path
>
> On Fri, Mar 20, 2026 at 02:35:42PM -0700, Tantilov, Emil S wrote:
> >
> >
> > On 3/20/2026 10:48 AM, Simon Horman wrote:
> > > 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
> > > ---
> > > idpf: fix xdp crash in soft reset error path
> > >
> > > This commit fixes a NULL pointer dereference that occurs when
> > > idpf_vport_open() fails during soft reset. The fix restores
> > > vport->xdp_prog in the error path and updates the restart check in
> > > idpf_xsk_pool_setup() to use IDPF_VPORT_UP instead of netif_running().
> > >
> > > > Fixes: 3d57b2c00f09 ("idpf: add XSk pool initialization")
> > >
> > > The Fixes: tag may not be targeting the correct commit. The primary
> > > bug being fixed is the NULL pointer dereference crash in
> > > idpf_xdp_setup_prog() that occurs when soft reset fails and vport-
> >xdp_prog is not restored.
> >
> > This is not exactly true, this is just one of the instances that would
> > cause idpf_qp_switch() to be called. [1]
> >
> > >
> > > Looking at the git history, this missing restoration was introduced
> > > in commit 705457e7211f ("idpf: implement XDP_SETUP_PROG in
> ndo_bpf
> > > for splitq"), where idpf_xdp_setup_prog() was first implemented.
> > > While commit
> > > 3d57b2c00f09 introduced the secondary issue with the netif_running()
> > > check, the main crash fix addresses code from commit 705457e7211f.
> > >
> > > Should the Fixes: tag point to commit 705457e7211f instead?
> >
> > The reason I chose commit 3d57b2c00f09 is because it is the commit
> > introducing the function where the crash is occurring:
> > [ 3179.284770] RIP: 0010:idpf_find_rxq_vec+0x17/0x30 [idpf] ...
> > [ 3179.291937] Call Trace:
> > [ 3179.292392] <TASK>
> > [ 3179.292843] idpf_qp_switch+0x25/0x820 [idpf]
> >
> > The setting of the restart variable is where the above commits "meet",
> > in that both conditions - netif_ruinning() and idpf_xdp_enabled() [1]
> > can be wrong:
> > https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git/tr
> > ee/drivers/net/ethernet/intel/idpf/xsk.c#n571
> >
> > which would end up calling idpf_qp_switch() instead of taking the
> > alternate path:
> > restart = idpf_xdp_enabled(vport) && netif_running(vport->netdev);
> > if (!restart)
> > goto pool;
> >
> > Which was introduced by 3d57b2c00f09.
>
> Thanks for the clarification.
> I agree that using 3d57b2c00f09 makes sense.
>
> ...
Tested-by: Patryk Holda <patryk.holda@intel.com>
^ 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