* Re: [Intel-wired-lan] [PATCH iwl-next v5 1/2] ethtool: treat RXH_GTP_TEID as intrinsically symmetric
From: Jakub Kicinski @ 2026-06-26 22:29 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260626054730.1126969-2-aleksandr.loktionov@intel.com>
On Fri, 26 Jun 2026 07:47:29 +0200 Aleksandr Loktionov wrote:
> A GTP tunnel uses the same TEID value in both directions of a flow;
> including TEID in the hash input does not break src/dst symmetry.
>
> ethtool_rxfh_config_is_sym() currently rejects any hash field bitmap
> that contains bits outside the four paired L3/L4 fields. This causes
> drivers that hash GTP flows on TEID to fail the kernel's preflight
> validation in ethtool_check_flow_types(), making it impossible for
> those drivers to support symmetric-xor transforms at all.
>
> Strip RXH_GTP_TEID from the bitmap before the paired-field check so
> that drivers may honestly report TEID hashing without blocking the
> configuration of symmetric transforms.
I don't know much about GTP, but "the Internet" does not seem to agree
with your claim:
The TEID uniquely identifies the GSN tunnel endpoints. The tunnels
for an uplink and a downlink are separate and use a different TEID.
https://docs.paloaltonetworks.com/service-providers/10-1/mobile-network-infrastructure-getting-started/gtp/mobile-network-protection-profile
So I don't think this will fly..
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-next v5 2/2] ice: implement symmetric RSS hash configuration
From: Jakub Kicinski @ 2026-06-26 22:26 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260626054730.1126969-3-aleksandr.loktionov@intel.com>
On Fri, 26 Jun 2026 07:47:30 +0200 Aleksandr Loktionov wrote:
> - /* Update the VSI's hash function */
> - if (rxfh->input_xfrm & RXH_XFRM_SYM_XOR)
> - hfunc = ICE_AQ_VSI_Q_OPT_RSS_HASH_SYM_TPLZ;
> + /* Handle RSS symmetric hash transformation */
> + if (rxfh->input_xfrm != RXH_XFRM_NO_CHANGE) {
> + u8 new_hfunc;
I think this is the very bad part. Please extract it out and send it as
a fix to net. Looks like any changes to RSS confing on ice randomly
enable xfrm sym. I isolated it to the ntuple.py test which just changes
the indir table, and the driver says:
ice 0000:e1:00.0 ens1f0np0: Hash function set to: Symmetric Toeplitz
Which we never asked for. I drafted this before seeing your reply:
--- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
@@ -3692,10 +3692,10 @@ ice_set_rxfh(struct net_device *netdev, struct ethtool_rxfh_param *rxfh,
struct netlink_ext_ack *extack)
{
struct ice_netdev_priv *np = netdev_priv(netdev);
- u8 hfunc = ICE_AQ_VSI_Q_OPT_RSS_HASH_TPLZ;
struct ice_vsi *vsi = np->vsi;
struct ice_pf *pf = vsi->back;
struct device *dev;
+ u8 hfunc;
int err;
dev = ice_pf_to_dev(pf);
@@ -3714,9 +3714,12 @@ ice_set_rxfh(struct net_device *netdev, struct ethtool_rxfh_param *rxfh,
return -EOPNOTSUPP;
}
- /* Update the VSI's hash function */
- if (rxfh->input_xfrm & RXH_XFRM_SYM_XOR)
+ if (rxfh->input_xfrm == RXH_XFRM_NO_CHANGE)
+ hfunc = vsi->rss_hfunc;
+ else if (rxfh->input_xfrm & RXH_XFRM_SYM_XOR)
hfunc = ICE_AQ_VSI_Q_OPT_RSS_HASH_SYM_TPLZ;
+ else /* input_xfrm == 0; core rejects any other value */
+ hfunc = ICE_AQ_VSI_Q_OPT_RSS_HASH_TPLZ;
err = ice_set_rss_hfunc(vsi, hfunc);
^ permalink raw reply
* [Intel-wired-lan] [tnguy-net-queue:dev-queue] BUILD SUCCESS 6937632f4ac9cf96ea5da199e220ededb3966f23
From: kernel test robot @ 2026-06-26 16:51 UTC (permalink / raw)
To: Intel Wired LAN
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git dev-queue
branch HEAD: 6937632f4ac9cf96ea5da199e220ededb3966f23 idpf: fix max_vport related crash on allocation error during init
elapsed time: 1205m
configs tested: 265
configs skipped: 11
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc defconfig gcc-16.1.0
arc randconfig-001 gcc-16.1.0
arc randconfig-001-20260626 gcc-13.4.0
arc randconfig-001-20260626 gcc-16.1.0
arc randconfig-002 gcc-16.1.0
arc randconfig-002-20260626 gcc-13.4.0
arc randconfig-002-20260626 gcc-16.1.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001 gcc-16.1.0
arm randconfig-001-20260626 gcc-13.4.0
arm randconfig-001-20260626 gcc-16.1.0
arm randconfig-002 gcc-16.1.0
arm randconfig-002-20260626 gcc-13.4.0
arm randconfig-002-20260626 gcc-16.1.0
arm randconfig-003 gcc-16.1.0
arm randconfig-003-20260626 gcc-13.4.0
arm randconfig-003-20260626 gcc-16.1.0
arm randconfig-004 gcc-16.1.0
arm randconfig-004-20260626 gcc-13.4.0
arm randconfig-004-20260626 gcc-16.1.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260626 clang-23
arm64 randconfig-001-20260626 gcc-8.5.0
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260626 clang-23
arm64 randconfig-002-20260626 gcc-8.5.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260626 clang-23
arm64 randconfig-003-20260626 gcc-8.5.0
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260626 clang-23
arm64 randconfig-004-20260626 gcc-8.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001 clang-23
csky randconfig-001-20260626 clang-23
csky randconfig-001-20260626 gcc-8.5.0
csky randconfig-002 clang-23
csky randconfig-002-20260626 clang-23
csky randconfig-002-20260626 gcc-8.5.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260626 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260626 gcc-11.5.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001 gcc-14
i386 buildonly-randconfig-001-20260626 gcc-14
i386 buildonly-randconfig-002 gcc-14
i386 buildonly-randconfig-002-20260626 gcc-14
i386 buildonly-randconfig-003 gcc-14
i386 buildonly-randconfig-003-20260626 gcc-14
i386 buildonly-randconfig-004 gcc-14
i386 buildonly-randconfig-004-20260626 gcc-14
i386 buildonly-randconfig-005 gcc-14
i386 buildonly-randconfig-005-20260626 gcc-14
i386 buildonly-randconfig-006 gcc-14
i386 buildonly-randconfig-006-20260626 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001 gcc-14
i386 randconfig-001-20260626 gcc-14
i386 randconfig-002 gcc-14
i386 randconfig-002-20260626 gcc-14
i386 randconfig-003 gcc-14
i386 randconfig-003-20260626 gcc-14
i386 randconfig-004 gcc-14
i386 randconfig-004-20260626 gcc-14
i386 randconfig-005 gcc-14
i386 randconfig-005-20260626 gcc-14
i386 randconfig-006 gcc-14
i386 randconfig-006-20260626 gcc-14
i386 randconfig-007 gcc-14
i386 randconfig-007-20260626 gcc-14
i386 randconfig-011 gcc-14
i386 randconfig-011-20260626 gcc-14
i386 randconfig-012 gcc-14
i386 randconfig-012-20260626 gcc-14
i386 randconfig-013 gcc-14
i386 randconfig-013-20260626 gcc-14
i386 randconfig-014 gcc-14
i386 randconfig-014-20260626 gcc-14
i386 randconfig-015 gcc-14
i386 randconfig-015-20260626 gcc-14
i386 randconfig-016 gcc-14
i386 randconfig-016-20260626 gcc-14
i386 randconfig-017 gcc-14
i386 randconfig-017-20260626 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260626 gcc-11.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260626 gcc-11.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
microblaze mmu_defconfig gcc-16.1.0
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips loongson2k_defconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 defconfig clang-23
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260626 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260626 gcc-11.5.0
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig clang-23
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allyesconfig clang-17
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001 gcc-8.5.0
parisc randconfig-001-20260626 gcc-8.5.0
parisc randconfig-002 gcc-8.5.0
parisc randconfig-002-20260626 gcc-8.5.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc ep88xc_defconfig gcc-16.1.0
powerpc motionpro_defconfig clang-23
powerpc randconfig-001 gcc-8.5.0
powerpc randconfig-001-20260626 gcc-8.5.0
powerpc randconfig-002 gcc-8.5.0
powerpc randconfig-002-20260626 gcc-8.5.0
powerpc64 randconfig-001 gcc-8.5.0
powerpc64 randconfig-001-20260626 gcc-8.5.0
powerpc64 randconfig-002 gcc-8.5.0
powerpc64 randconfig-002-20260626 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv nommu_k210_sdcard_defconfig gcc-16.1.0
riscv randconfig-001 clang-23
riscv randconfig-001-20260626 clang-23
riscv randconfig-002 clang-23
riscv randconfig-002-20260626 clang-23
s390 allmodconfig clang-17
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 clang-23
s390 randconfig-001-20260626 clang-23
s390 randconfig-002 clang-23
s390 randconfig-002-20260626 clang-23
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allyesconfig clang-17
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh randconfig-001 clang-23
sh randconfig-001-20260626 clang-23
sh randconfig-002 clang-23
sh randconfig-002-20260626 clang-23
sparc allnoconfig clang-23
sparc defconfig gcc-16.1.0
sparc randconfig-001 gcc-12.5.0
sparc randconfig-001-20260626 gcc-12.5.0
sparc randconfig-002 gcc-12.5.0
sparc randconfig-002-20260626 gcc-12.5.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-12.5.0
sparc64 randconfig-001-20260626 gcc-12.5.0
sparc64 randconfig-002 gcc-12.5.0
sparc64 randconfig-002-20260626 gcc-12.5.0
um allmodconfig clang-17
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 gcc-12.5.0
um randconfig-001-20260626 gcc-12.5.0
um randconfig-002 gcc-12.5.0
um randconfig-002-20260626 gcc-12.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 gcc-14
x86_64 buildonly-randconfig-001-20260626 gcc-14
x86_64 buildonly-randconfig-002 gcc-14
x86_64 buildonly-randconfig-002-20260626 gcc-14
x86_64 buildonly-randconfig-003 gcc-14
x86_64 buildonly-randconfig-003-20260626 gcc-14
x86_64 buildonly-randconfig-004 gcc-14
x86_64 buildonly-randconfig-004-20260626 gcc-14
x86_64 buildonly-randconfig-005 gcc-14
x86_64 buildonly-randconfig-005-20260626 gcc-14
x86_64 buildonly-randconfig-006 gcc-14
x86_64 buildonly-randconfig-006-20260626 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260626 clang-22
x86_64 randconfig-002-20260626 clang-22
x86_64 randconfig-003-20260626 clang-22
x86_64 randconfig-004-20260626 clang-22
x86_64 randconfig-005-20260626 clang-22
x86_64 randconfig-006-20260626 clang-22
x86_64 randconfig-011 gcc-14
x86_64 randconfig-011-20260626 gcc-14
x86_64 randconfig-012 gcc-14
x86_64 randconfig-012-20260626 gcc-14
x86_64 randconfig-013 gcc-14
x86_64 randconfig-013-20260626 gcc-14
x86_64 randconfig-014 gcc-14
x86_64 randconfig-014-20260626 gcc-14
x86_64 randconfig-015 gcc-14
x86_64 randconfig-015-20260626 gcc-14
x86_64 randconfig-016 gcc-14
x86_64 randconfig-016-20260626 gcc-14
x86_64 randconfig-071 gcc-14
x86_64 randconfig-071-20260626 gcc-14
x86_64 randconfig-072 gcc-14
x86_64 randconfig-072-20260626 gcc-14
x86_64 randconfig-073 gcc-14
x86_64 randconfig-073-20260626 gcc-14
x86_64 randconfig-074 gcc-14
x86_64 randconfig-074-20260626 gcc-14
x86_64 randconfig-075 gcc-14
x86_64 randconfig-075-20260626 gcc-14
x86_64 randconfig-076 gcc-14
x86_64 randconfig-076-20260626 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allyesconfig clang-20
xtensa randconfig-001 gcc-12.5.0
xtensa randconfig-001-20260626 gcc-12.5.0
xtensa randconfig-002 gcc-12.5.0
xtensa randconfig-002-20260626 gcc-12.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [Intel-wired-lan] [PATCH net] e1000e: fix IRQ leak when request_irq() fails in e1000_request_msix()
From: Jiayuan Chen @ 2026-06-26 8:39 UTC (permalink / raw)
To: netdev
Cc: Jiayuan Chen, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Garzik, Bruce Allan, intel-wired-lan, linux-kernel
An internal syzbot instance reported the warning below.
comedi (comedi_parport) lets userspace request_irq() an arbitrary IRQ
number and can thus grab one of e1000e's MSI-X vectors. When
e1000_request_msix() then fails partway through, it returned without
freeing the vectors it had already requested; pci_disable_msix() later
tears those descriptors down while their irqaction is still attached,
leaking the /proc/irq entry.
Free the already requested IRQs on the error path.
genirq: Flags mismatch irq 28. 00200000 (eth1-tx-0) vs. 00200000 (comedi_parport)
remove_proc_entry: removing non-empty directory 'irq/27', leaking at least 'eth1-rx-0'
WARNING: fs/proc/generic.c:742 at remove_proc_entry+0x436/0x560, CPU#3: ip/445
Modules linked in:
CPU: 3 UID: 0 PID: 445 Comm: ip Not tainted 7.1.0+ #284 PREEMPT
RIP: 0010:remove_proc_entry (fs/proc/generic.c:742 (discriminator 4))
PKRU: 55555554
Call Trace:
<TASK>
unregister_irq_proc (kernel/irq/proc.c:406)
free_desc (kernel/irq/irqdesc.c:482)
irq_free_descs (kernel/irq/irqdesc.c:874 kernel/irq/irqdesc.c:865)
irq_domain_free_irqs (kernel/irq/irqdomain.c:1917)
msi_domain_free_locked.part.0 (kernel/irq/msi.c:1619 kernel/irq/msi.c:1645)
msi_domain_free_irqs_all_locked (kernel/irq/msi.c:1632)
pci_msi_teardown_msi_irqs (drivers/pci/msi/irqdomain.c:28)
pci_free_msi_irqs (drivers/pci/msi/msi.c:925)
pci_disable_msix (drivers/pci/msi/api.c:200 drivers/pci/msi/api.c:193)
e1000_request_irq (drivers/net/ethernet/intel/e1000e/netdev.c:2028)
e1000e_open (drivers/net/ethernet/intel/e1000e/netdev.c:4681)
__dev_open (net/core/dev.c:1702)
netif_change_flags (net/core/dev.c:9806)
do_setlink.isra.0 (net/core/rtnetlink.c:3207 (discriminator 1))
rtnetlink_rcv_msg (net/core/rtnetlink.c:7068)
netlink_rcv_skb (net/netlink/af_netlink.c:2556)
Fixes: 4662e82b2cb4 ("e1000e: add support for new 82574L part")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Assisted-by: Claude:claude-opus-4-8
---
drivers/net/ethernet/intel/e1000e/netdev.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 808e5cddd6a9..19b9823c5679 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -2099,7 +2099,7 @@ void e1000e_set_interrupt_capability(struct e1000_adapter *adapter)
static int e1000_request_msix(struct e1000_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
- int err = 0, vector = 0;
+ int err = 0, vector = 0, i;
if (strlen(netdev->name) < (IFNAMSIZ - 5))
snprintf(adapter->rx_ring->name,
@@ -2111,7 +2111,7 @@ static int e1000_request_msix(struct e1000_adapter *adapter)
e1000_intr_msix_rx, 0, adapter->rx_ring->name,
netdev);
if (err)
- return err;
+ goto err_free;
adapter->rx_ring->itr_register = adapter->hw.hw_addr +
E1000_EITR_82574(vector);
adapter->rx_ring->itr_val = adapter->itr;
@@ -2127,7 +2127,7 @@ static int e1000_request_msix(struct e1000_adapter *adapter)
e1000_intr_msix_tx, 0, adapter->tx_ring->name,
netdev);
if (err)
- return err;
+ goto err_free;
adapter->tx_ring->itr_register = adapter->hw.hw_addr +
E1000_EITR_82574(vector);
adapter->tx_ring->itr_val = adapter->itr;
@@ -2136,11 +2136,16 @@ static int e1000_request_msix(struct e1000_adapter *adapter)
err = request_irq(adapter->msix_entries[vector].vector,
e1000_msix_other, 0, netdev->name, netdev);
if (err)
- return err;
+ goto err_free;
e1000_configure_msix(adapter);
return 0;
+
+err_free:
+ for (i = vector - 1; i >= 0; i--)
+ free_irq(adapter->msix_entries[i].vector, netdev);
+ return err;
}
/**
--
2.43.0
^ permalink raw reply related
* Re: [Intel-wired-lan] [PATCH net v7 3/4] iavf: send MAC change request synchronously
From: Kwapulinski, Piotr @ 2026-06-26 15:04 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, netdev@vger.kernel.org
Cc: intel-wired-lan@lists.osuosl.org, Kitszel, Przemyslaw,
Loktionov, Aleksandr, Keller, Jacob E, horms@kernel.org,
Nguyen, Anthony L, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, stable@vger.kernel.org
In-Reply-To: <20260623101800.991293-4-jtornosm@redhat.com>
>-----Original Message-----
>From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Jose Ignacio Tornos Martinez
>Sent: Tuesday, June 23, 2026 12:18 PM
>To: netdev@vger.kernel.org
>Cc: intel-wired-lan@lists.osuosl.org; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>; horms@kernel.org; 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>; stable@vger.kernel.org
>Subject: [Intel-wired-lan] [PATCH net v7 3/4] iavf: send MAC change request synchronously
>
>After commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations"), iavf_set_mac() is called with the netdev instance lock already held.
>
>The function queues a MAC address change request via
>iavf_replace_primary_mac() and then waits for completion. However, in the current flow, the actual virtchnl message is sent by the watchdog task, which also needs to acquire the netdev lock to run. Additionally, the adminq_task which processes virtchnl responses also needs the netdev lock.
>
>This creates a deadlock scenario:
>1. iavf_set_mac() holds netdev lock and waits for MAC change 2. Watchdog needs netdev lock to send the request -> blocked 3. Even if request is sent, adminq_task needs netdev lock to process
> PF response -> blocked
>4. MAC change times out after 2.5 seconds 5. iavf_set_mac() returns -EAGAIN
>
>This particularly affects VFs during bonding setup when multiple VFs are enslaved in quick succession.
>
>Fix by implementing a synchronous MAC change operation similar to the approach used in commit fdadbf6e84c4 ("iavf: fix incorrect reset handling in callbacks").
>
>The solution:
>1. Send the virtchnl ADD_ETH_ADDR message directly (not via watchdog) 2. Poll the admin queue hardware directly for responses 3. Process all received messages (including non-MAC messages) 4. Return when MAC change completes or times out
>
>A new generic function iavf_poll_virtchnl_response() is introduced that can be reused for any future synchronous virtchnl operations. It takes a callback to check completion, allowing flexible condition checking.
>
>This allows the operation to complete synchronously while holding netdev_lock, without relying on watchdog or adminq_task. The function can sleep for up to 2.5 seconds polling hardware, but this is acceptable since netdev_lock is per-device and only serializes operations on the same interface.
>
>To support this, change iavf_add_ether_addrs() to return an error code instead of void, allowing callers to detect failures. Additionally, export iavf_mac_add_reject() to enable proper rollback on local failures (timeouts, send errors) - PF rejections are already handled automatically by iavf_virtchnl_completion().
>
>Remove vc_waitqueue entirely because iavf_set_mac was the only waiter on this waitqueue and after the changes it is not needed.
>
>Fixes: ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations")
>cc: stable@vger.kernel.org
>Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
>---
>v7: Rebase on current net tree
> Remove the multi-batch processing loop from version 6 according to Przemek
> Kitszel review: the loop cannot work without polling between iterations
> since the second call would fail the current_op check. Multi-batch scenario
> is extremely rare; send first batch and let watchdog handle remainder as v5
> did
>v6: https://lore.kernel.org/all/20260619061321.8554-4-jtornosm@redhat.com/
>
> drivers/net/ethernet/intel/iavf/iavf.h | 11 ++-
> drivers/net/ethernet/intel/iavf/iavf_main.c | 85 ++++++++++++----
> .../net/ethernet/intel/iavf/iavf_virtchnl.c | 99 +++++++++++++++++--
> 3 files changed, 165 insertions(+), 30 deletions(-)
>
>diff --git a/drivers/net/ethernet/intel/iavf/iavf.h b/drivers/net/ethernet/intel/iavf/iavf.h
>index 050f8241ef5e..5fcbfa0ca855 100644
>--- a/drivers/net/ethernet/intel/iavf/iavf.h
>+++ b/drivers/net/ethernet/intel/iavf/iavf.h
>@@ -259,7 +259,6 @@ struct iavf_adapter {
> struct work_struct adminq_task;
> struct work_struct finish_config;
> wait_queue_head_t down_waitqueue;
>- wait_queue_head_t vc_waitqueue;
> struct iavf_q_vector *q_vectors;
> struct list_head vlan_filter_list;
> int num_vlan_filters;
>@@ -588,8 +587,9 @@ void iavf_configure_queues(struct iavf_adapter *adapter); void iavf_enable_queues(struct iavf_adapter *adapter); void iavf_disable_queues(struct iavf_adapter *adapter); void iavf_map_queues(struct iavf_adapter *adapter); -void iavf_add_ether_addrs(struct iavf_adapter *adapter);
>+int iavf_add_ether_addrs(struct iavf_adapter *adapter);
> void iavf_del_ether_addrs(struct iavf_adapter *adapter);
>+void iavf_mac_add_reject(struct iavf_adapter *adapter);
> void iavf_add_vlans(struct iavf_adapter *adapter); void iavf_del_vlans(struct iavf_adapter *adapter); void iavf_set_promiscuous(struct iavf_adapter *adapter); @@ -606,6 +606,13 @@ void iavf_disable_vlan_stripping(struct iavf_adapter *adapter); void iavf_virtchnl_completion(struct iavf_adapter *adapter,
> enum virtchnl_ops v_opcode,
> enum iavf_status v_retval, u8 *msg, u16 msglen);
>+int iavf_poll_virtchnl_response(struct iavf_adapter *adapter,
>+ struct iavf_arq_event_info *event,
>+ bool (*condition)(struct iavf_adapter *adapter,
>+ const void *data,
>+ enum virtchnl_ops v_op),
>+ const void *cond_data,
>+ unsigned int timeout_ms);
> int iavf_config_rss(struct iavf_adapter *adapter); void iavf_cfg_queues_bw(struct iavf_adapter *adapter); void iavf_cfg_queues_quanta_size(struct iavf_adapter *adapter); diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
>index 630388e9d28c..3fa288e3798a 100644
>--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
>+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
>@@ -1029,6 +1029,60 @@ static bool iavf_is_mac_set_handled(struct net_device *netdev,
> return ret;
> }
>
>+/**
>+ * iavf_mac_change_done - Check if MAC change completed
>+ * @adapter: board private structure
>+ * @data: MAC address being checked (as const void *)
>+ * @v_op: virtchnl opcode from processed message
>+ *
>+ * Callback for iavf_poll_virtchnl_response() to check if MAC change completed.
>+ *
>+ * Return: true if MAC change completed, false otherwise */ static
>+bool iavf_mac_change_done(struct iavf_adapter *adapter,
>+ const void *data, enum virtchnl_ops v_op) {
>+ const u8 *addr = data;
>+
>+ return iavf_is_mac_set_handled(adapter->netdev, addr); }
>+
>+/**
>+ * iavf_set_mac_sync - Synchronously change MAC address
>+ * @adapter: board private structure
>+ * @addr: MAC address to set
>+ *
>+ * Send MAC change request to PF and poll admin queue for response.
>+ * Caller must hold netdev_lock. This can sleep for up to 2.5 seconds.
>+ * Event buffer is allocated before sending to avoid state mismatch if
>+ * allocation fails after message is sent to PF.
>+ *
>+ * Return: 0 on success, negative on failure */ static int
>+iavf_set_mac_sync(struct iavf_adapter *adapter, const u8 *addr) {
>+ struct iavf_arq_event_info event;
>+ int ret;
>+
>+ netdev_assert_locked(adapter->netdev);
>+
>+ event.buf_len = IAVF_MAX_AQ_BUF_SIZE;
>+ event.msg_buf = kzalloc(event.buf_len, GFP_KERNEL);
>+ if (!event.msg_buf)
>+ return -ENOMEM;
>+
>+ ret = iavf_add_ether_addrs(adapter);
>+ if (ret)
>+ goto out;
>+
>+ ret = iavf_poll_virtchnl_response(adapter, &event,
>+ iavf_mac_change_done, addr, 2500);
>+
>+out:
>+ kfree(event.msg_buf);
>+ return ret;
>+}
>+
> /**
> * iavf_set_mac - NDO callback to set port MAC address
> * @netdev: network interface device structure @@ -1049,25 +1103,23 @@ static int iavf_set_mac(struct net_device *netdev, void *p)
> return -EADDRNOTAVAIL;
>
> ret = iavf_replace_primary_mac(adapter, addr->sa_data);
>-
> if (ret)
> return ret;
>
>- ret = wait_event_interruptible_timeout(adapter->vc_waitqueue,
>- iavf_is_mac_set_handled(netdev, addr->sa_data),
>- msecs_to_jiffies(2500));
>-
>- /* If ret < 0 then it means wait was interrupted.
>- * If ret == 0 then it means we got a timeout.
>- * else it means we got response for set MAC from PF,
>- * check if netdev MAC was updated to requested MAC,
>- * if yes then set MAC succeeded otherwise it failed return -EACCES
>- */
>- if (ret < 0)
>+ ret = iavf_set_mac_sync(adapter, addr->sa_data);
>+ if (ret) {
>+ /* Rollback only if send failed (message never reached PF).
>+ * Don't rollback on timeout (-EAGAIN) because the message was
>+ * sent and PF will eventually respond. When the response arrives,
>+ * iavf_virtchnl_completion() will handle rollback (on PF error)
>+ * or acceptance (on PF success) automatically.
>+ */
>+ if (ret != -EAGAIN) {
>+ iavf_mac_add_reject(adapter);
>+ ether_addr_copy(adapter->hw.mac.addr, netdev->dev_addr);
>+ }
> return ret;
>-
>- if (!ret)
>- return -EAGAIN;
>+ }
>
> if (!ether_addr_equal(netdev->dev_addr, addr->sa_data))
> return -EACCES;
>@@ -5397,9 +5449,6 @@ static int iavf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> /* Setup the wait queue for indicating transition to down status */
> init_waitqueue_head(&adapter->down_waitqueue);
>
>- /* Setup the wait queue for indicating virtchannel events */
>- init_waitqueue_head(&adapter->vc_waitqueue);
>-
> INIT_LIST_HEAD(&adapter->ptp.aq_cmds);
> init_waitqueue_head(&adapter->ptp.phc_time_waitqueue);
> mutex_init(&adapter->ptp.aq_cmd_lock);
>diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
>index ec234cc8bd9d..e6b7e8f82c7c 100644
>--- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
>+++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
>@@ -2,6 +2,7 @@
> /* Copyright(c) 2013 - 2018 Intel Corporation. */
>
> #include <linux/net/intel/libie/rx.h>
>+#include <net/netdev_lock.h>
>
> #include "iavf.h"
> #include "iavf_ptp.h"
>@@ -555,20 +556,23 @@ iavf_set_mac_addr_type(struct virtchnl_ether_addr *virtchnl_ether_addr,
> * @adapter: adapter structure
> *
> * Request that the PF add one or more addresses to our filters.
>- **/
>-void iavf_add_ether_addrs(struct iavf_adapter *adapter)
>+ *
>+ * Return: 0 on success, negative on failure */ int
>+iavf_add_ether_addrs(struct iavf_adapter *adapter)
> {
> struct virtchnl_ether_addr_list *veal;
> struct iavf_mac_filter *f;
> int i = 0, count = 0;
> bool more = false;
> size_t len;
>+ int ret;
The patch looks good. Minor suggestion:
- int i = 0, count = 0;
+ int i = 0, count = 0, ret;
Please retain RCT.
Thank you.
Piotr
>
> if (adapter->current_op != VIRTCHNL_OP_UNKNOWN) {
> /* bail because we already have a command pending */
> dev_err(&adapter->pdev->dev, "Cannot add filters, command %d pending\n",
> adapter->current_op);
>- return;
>+ return -EBUSY;
> }
>
> spin_lock_bh(&adapter->mac_vlan_list_lock);
>@@ -580,7 +584,7 @@ void iavf_add_ether_addrs(struct iavf_adapter *adapter)
> if (!count) {
> adapter->aq_required &= ~IAVF_FLAG_AQ_ADD_MAC_FILTER;
> spin_unlock_bh(&adapter->mac_vlan_list_lock);
>- return;
>+ return 0;
> }
> adapter->current_op = VIRTCHNL_OP_ADD_ETH_ADDR;
>
>@@ -594,8 +598,9 @@ void iavf_add_ether_addrs(struct iavf_adapter *adapter)
>
> veal = kzalloc(len, GFP_ATOMIC);
> if (!veal) {
>+ adapter->current_op = VIRTCHNL_OP_UNKNOWN;
> spin_unlock_bh(&adapter->mac_vlan_list_lock);
>- return;
>+ return -ENOMEM;
> }
>
> veal->vsi_id = adapter->vsi_res->vsi_id; @@ -615,8 +620,15 @@ void iavf_add_ether_addrs(struct iavf_adapter *adapter)
>
> spin_unlock_bh(&adapter->mac_vlan_list_lock);
>
>- iavf_send_pf_msg(adapter, VIRTCHNL_OP_ADD_ETH_ADDR, (u8 *)veal, len);
>+ ret = iavf_send_pf_msg(adapter, VIRTCHNL_OP_ADD_ETH_ADDR, (u8 *)veal,
>+len);
> kfree(veal);
>+ if (ret) {
>+ dev_err(&adapter->pdev->dev,
>+ "Unable to send ADD_ETH_ADDR message to PF, error %d\n", ret);
>+ adapter->current_op = VIRTCHNL_OP_UNKNOWN;
>+ }
>+
>+ return ret;
> }
>
> /**
>@@ -712,8 +724,8 @@ static void iavf_mac_add_ok(struct iavf_adapter *adapter)
> * @adapter: adapter structure
> *
> * Remove filters from list based on PF response.
>- **/
>-static void iavf_mac_add_reject(struct iavf_adapter *adapter)
>+ */
>+void iavf_mac_add_reject(struct iavf_adapter *adapter)
> {
> struct net_device *netdev = adapter->netdev;
> struct iavf_mac_filter *f, *ftmp;
>@@ -2364,7 +2376,6 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
> iavf_mac_add_reject(adapter);
> /* restore administratively set MAC address */
> ether_addr_copy(adapter->hw.mac.addr, netdev->dev_addr);
>- wake_up(&adapter->vc_waitqueue);
> break;
> case VIRTCHNL_OP_DEL_ETH_ADDR:
> dev_err(&adapter->pdev->dev, "Failed to delete MAC filter, error %s\n", @@ -2555,7 +2566,6 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
> eth_hw_addr_set(netdev, adapter->hw.mac.addr);
> netif_addr_unlock_bh(netdev);
> }
>- wake_up(&adapter->vc_waitqueue);
> break;
> case VIRTCHNL_OP_GET_STATS: {
> struct iavf_eth_stats *stats =
>@@ -2950,3 +2960,72 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
> } /* switch v_opcode */
> adapter->current_op = VIRTCHNL_OP_UNKNOWN; }
>+
>+/**
>+ * iavf_poll_virtchnl_response - Poll admin queue for virtchnl response
>+ * @adapter: adapter structure
>+ * @event: pre-allocated event buffer to use for polling
>+ * @condition: callback to check if desired response received
>+ * @cond_data: context data passed to condition callback
>+ * @timeout_ms: maximum time to wait in milliseconds
>+ *
>+ * Polls the admin queue and processes all incoming virtchnl messages.
>+ * After processing each valid message, calls the condition callback to
>+check
>+ * if the expected response has been received. The callback receives
>+the opcode
>+ * of the processed message to identify which response was received.
>+Continues
>+ * polling until the callback returns true or timeout expires.
>+ *
>+ * Caller must allocate event buffer before sending any messages to PF
>+to avoid
>+ * state mismatch if allocation fails after message is sent.
>+ *
>+ * Caller must hold netdev_lock. This can sleep for up to timeout_ms
>+while
>+ * polling hardware.
>+ *
>+ * Return: 0 on success (condition met), -EAGAIN on timeout, or error
>+code */ int iavf_poll_virtchnl_response(struct iavf_adapter *adapter,
>+ struct iavf_arq_event_info *event,
>+ bool (*condition)(struct iavf_adapter *adapter,
>+ const void *data,
>+ enum virtchnl_ops v_op),
>+ const void *cond_data,
>+ unsigned int timeout_ms)
>+{
>+ struct iavf_hw *hw = &adapter->hw;
>+ enum virtchnl_ops received_op;
>+ unsigned long timeout;
>+ int ret = -EAGAIN;
>+ u16 pending = 0;
>+ u32 v_retval;
Most of these variables may be declared inside the below statements.
Reviewed-by Piotr Kwapulinski <piotr.kwapulinski@intel.com>
Piotr
>+
>+ netdev_assert_locked(adapter->netdev);
>+
>+ timeout = jiffies + msecs_to_jiffies(timeout_ms);
>+ do {
>+ if (!pending)
>+ usleep_range(50, 75);
>+
>+ if (iavf_clean_arq_element(hw, event, &pending) == IAVF_SUCCESS) {
>+ received_op = (enum virtchnl_ops)le32_to_cpu(event->desc.cookie_high);
>+ if (received_op != VIRTCHNL_OP_UNKNOWN) {
>+ v_retval = le32_to_cpu(event->desc.cookie_low);
>+
>+ iavf_virtchnl_completion(adapter, received_op,
>+ (enum iavf_status)v_retval,
>+ event->msg_buf, event->msg_len);
>+
>+ if (condition(adapter, cond_data, received_op)) {
>+ ret = 0;
>+ break;
>+ }
>+ }
>+
>+ memset(event->msg_buf, 0, IAVF_MAX_AQ_BUF_SIZE);
>+
>+ if (pending)
>+ continue;
>+ }
>+ } while (time_before(jiffies, timeout));
>+
>+ return ret;
>+}
>--
>2.54.0
>
>
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl v3] ice: retry reading NVM if admin queue returns EBUSY
From: Przemek Kitszel @ 2026-06-26 11:46 UTC (permalink / raw)
To: Robert Malz; +Cc: anthony.l.nguyen, intel-wired-lan, Simon Horman, netdev
In-Reply-To: <CADcc-bwC4FGQSGyRcnj2ZpGT5+0Q6mjQd-FTCB-mCmmwYrC8Qw@mail.gmail.com>
On 6/26/26 10:15, Robert Malz wrote:
> Hey Przemek,
> I ran some tests and unfortunately, the following sentence from the
> datasheet is true:
> "For specific resources, such as Change Lock (0x0003) and Global Config Lock
> (0x0004), this field is used by software to override the default timeout for the
> operation, and also to specify the timeout used for this operation."
>
> This means we can only change a default timeout for 0x0003 and 0x0004
> but not for 0x0001 (NVM resource).
> Whatever timeout I provide FW defaults to 0xB88
> Input:
> [ 2209.656758] ice 0000:31:00.0: CQ CMD: opcode 0x0008, flags 0x2000,
> datalen 0x0000, retval 0x0000
> [ 2209.656760] ice 0000:31:00.0: cookie (h,l) 0x00000000 0x00000000
> [ 2209.656761] ice 0000:31:00.0: param (0,1) 0x00010001 0x00000BB9
> Output:
> [ 2209.656927] ice 0000:31:00.0: CQ CMD: opcode 0x0008, flags 0x2003,
> datalen 0x0000, retval 0x0000
> [ 2209.656929] ice 0000:31:00.0: cookie (h,l) 0x00000000 0x00000000
> [ 2209.656931] ice 0000:31:00.0: param (0,1) 0x00010001 0x00000BB8
>
> Correct me If I'm wrong, but the only way to properly handle it is to
> ensure the resource is locked and released between every
> ice_acquire_nvm call.
> I'll start working on this.
thank you for checking out!
I agree that simple retries with improved (refactored) locking will be
good solution.
Failure to lock should count as an unsuccessful attempt, with possible
retry after a sleep.
>
> Regards,
> Robert
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net v7 3/4] iavf: send MAC change request synchronously
From: Jose Ignacio Tornos Martinez @ 2026-06-26 10:54 UTC (permalink / raw)
To: horms
Cc: aleksandr.loktionov, anthony.l.nguyen, davem, edumazet,
intel-wired-lan, jacob.e.keller, jtornosm, kuba, netdev, pabeni,
przemyslaw.kitszel
In-Reply-To: <20260624163148.1146093-2-horms@kernel.org>
>> if (!ether_addr_equal(netdev->dev_addr, addr->sa_data))
>> return -EACCES;
> [Severity: High]
> Will this cause a persistent state mismatch if a timeout is followed by a
> retry?
>
> If iavf_set_mac_sync() times out, it returns -EAGAIN and bypasses this
> rollback, leaving adapter->hw.mac.addr updated but netdev->dev_addr at the
> old MAC.
>
> If the user then retries before the PF asynchronously completes the original
> request, iavf_add_ether_addrs() returns -EBUSY. Since -EBUSY != -EAGAIN,
> the rollback runs, forcibly reverting adapter->hw.mac.addr to the old MAC.
>
> When the PF's delayed success response finally arrives,
> iavf_virtchnl_completion() sees the old MAC in both hw.mac.addr and
> netdev->dev_addr, bypassing the netdev MAC update. The PF hardware is now
> programmed with the new MAC, but the kernel retains the old MAC, dropping
> traffic.
This scenario requires an extremely narrow timing window: a 2.5s PF timeout
(rare in normal operation, PF typically responds much faster), followed by an
immediate retry before adminq_task clears current_op (microsecond window).
Even if this race occurs, it's recoverable - the retry fails with -EBUSY
and the user retries again successfully. This is a transient failure, not
permanent state corruption.
>> if (adapter->current_op != VIRTCHNL_OP_UNKNOWN) {
>> /* bail because we already have a command pending */
>> dev_err(&adapter->pdev->dev, "Cannot add filters, command %d pending\n",
>> adapter->current_op);
>> - return;
>> + return -EBUSY;
>> }
>
> [Severity: High]
> Could routine background tasks cause MAC changes to frequently fail?
>
> The watchdog task routinely sets adapter->current_op for background commands
> like VIRTCHNL_OP_GET_STATS. If iavf_set_mac() is called during this window,
> iavf_set_mac_sync() will hit this check and immediately fail the MAC change
> with -EBUSY.
>
> Because there is no retry logic in iavf_set_mac(), this error propagates
> directly to userspace, making MAC address configuration randomly fail based
> on watchdog timing.
Background virtchnl operations (like GET_STATS) complete quickly, typically
within milliseconds. The collision window is very small.
Fail-fast with -EBUSY is semantically correct and allows user-space retry.
If a collision occurs, it's spurious and recoverable immediately on retry.
This is acceptable compared to the complexity and deadlock risks of queuing
or waiting for background operations to complete while holding netdev_lock.
>> -static void iavf_mac_add_reject(struct iavf_adapter *adapter)
>> + */
>> +void iavf_mac_add_reject(struct iavf_adapter *adapter)
>> {
>> struct net_device *netdev = adapter->netdev;
>> struct iavf_mac_filter *f, *ftmp;
>
> [Severity: Medium]
> Does exporting and reusing iavf_mac_add_reject() for local rollback cause
> unintended background MAC changes?
>
> When the user requests a MAC address that is already in the filter list
> (e.g., a secondary MAC), iavf_add_filter() sets f->is_new_mac = false and
> f->add = true, and flags IAVF_FLAG_AQ_ADD_MAC_FILTER.
>
> If the synchronous operation fails locally (like the -EBUSY return above),
> iavf_set_mac() calls this function. However, iavf_mac_add_reject() only
> clears the pending state and removes the filter if f->is_new_mac is true:
>
> if (f->is_new_mac) {
> list_del(&f->list);
> kfree(f);
> }
>
> Reused filters are ignored, leaving f->add = true and the
> IAVF_FLAG_AQ_ADD_MAC_FILTER flag active. The background watchdog task will
> eventually process this flag and blindly send the MAC configuration to the
> PF, even though the VF already aborted the operation locally.
This scenario only occurs when setting the primary MAC to an address that
already exists as a secondary MAC in the filter list - an extremely rare
configuration.
Even if this occurs and the watchdog later sends the MAC to the PF, it is
harmless: the MAC is already configured on the PF (as a secondary), so the
redundant ADD_ETH_ADDR message has no adverse effect.
The common case - changing primary MAC to a new address - uses is_new_mac =
true and is handled correctly by the rollback logic.
These concerns represent theoretical edge cases that are extremely unlikely
in practice. The synchronous approach fixes a reproducible deadlock affecting
all users in production, allowing the user to retry and complete the
operation. The trade-off is justified.
^ permalink raw reply
* [Intel-wired-lan] [tnguy-next-queue:dev-queue] BUILD SUCCESS 5cca9023832afcdb4d8121797e52796bbbf94e2e
From: kernel test robot @ 2026-06-26 10:27 UTC (permalink / raw)
To: Intel Wired LAN
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git dev-queue
branch HEAD: 5cca9023832afcdb4d8121797e52796bbbf94e2e ice: refactor ice_sched_cfg_agg to take agg_info pointer
elapsed time: 803m
configs tested: 149
configs skipped: 12
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001-20260626 gcc-11.5.0
arc randconfig-002-20260626 gcc-9.5.0
arm allnoconfig clang-17
arm allyesconfig gcc-16.1.0
arm randconfig-001-20260626 gcc-13.4.0
arm randconfig-002-20260626 clang-23
arm randconfig-003-20260626 gcc-13.4.0
arm randconfig-004-20260626 clang-21
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
hexagon allmodconfig clang-23
hexagon allnoconfig clang-23
hexagon randconfig-001-20260626 clang-23
hexagon randconfig-002-20260626 clang-17
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260626 gcc-14
i386 buildonly-randconfig-002-20260626 gcc-14
i386 buildonly-randconfig-003-20260626 gcc-14
i386 buildonly-randconfig-004-20260626 gcc-12
i386 buildonly-randconfig-005-20260626 gcc-14
i386 buildonly-randconfig-006-20260626 gcc-14
i386 defconfig clang-22
i386 randconfig-001-20260626 clang-22
i386 randconfig-002-20260626 gcc-14
i386 randconfig-003-20260626 clang-22
i386 randconfig-004-20260626 clang-22
i386 randconfig-005-20260626 gcc-14
i386 randconfig-006-20260626 gcc-14
i386 randconfig-007-20260626 gcc-14
i386 randconfig-011-20260626 gcc-14
i386 randconfig-012-20260626 clang-22
i386 randconfig-013-20260626 clang-22
i386 randconfig-014-20260626 gcc-14
i386 randconfig-015-20260626 gcc-14
i386 randconfig-016-20260626 clang-22
i386 randconfig-017-20260626 clang-22
loongarch allmodconfig clang-19
loongarch allnoconfig clang-20
loongarch defconfig clang-23
loongarch randconfig-001-20260626 gcc-16.1.0
loongarch randconfig-002-20260626 clang-18
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig gcc-16.1.0
m68k defconfig gcc-16.1.0
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig gcc-16.1.0
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips rbtx49xx_defconfig gcc-16.1.0
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20260626 gcc-11.5.0
nios2 randconfig-002-20260626 gcc-8.5.0
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig gcc-16.1.0
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260626 gcc-8.5.0
parisc randconfig-002-20260626 gcc-12.5.0
parisc64 defconfig gcc-16.1.0
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig gcc-16.1.0
powerpc randconfig-001-20260626 clang-23
powerpc randconfig-002-20260626 gcc-11.5.0
powerpc64 randconfig-001-20260626 clang-17
powerpc64 randconfig-002-20260626 gcc-13.4.0
riscv allmodconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig clang-23
riscv randconfig-001-20260626 gcc-11.5.0
riscv randconfig-002-20260626 clang-23
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig clang-18
s390 randconfig-001-20260626 clang-23
s390 randconfig-002-20260626 gcc-8.5.0
sh allmodconfig gcc-16.1.0
sh allnoconfig gcc-16.1.0
sh allyesconfig gcc-16.1.0
sh defconfig gcc-16.1.0
sh randconfig-001-20260626 gcc-9.5.0
sh randconfig-002-20260626 gcc-16.1.0
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260626 gcc-12.5.0
sparc randconfig-002-20260626 gcc-8.5.0
sparc64 allmodconfig clang-20
sparc64 defconfig clang-23
sparc64 randconfig-001-20260626 clang-20
sparc64 randconfig-002-20260626 clang-20
um allmodconfig clang-17
um allnoconfig clang-17
um allyesconfig gcc-14
um defconfig clang-23
um i386_defconfig gcc-14
um randconfig-001-20260626 clang-18
um randconfig-002-20260626 clang-23
um x86_64_defconfig clang-23
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001-20260626 clang-22
x86_64 buildonly-randconfig-002-20260626 gcc-14
x86_64 buildonly-randconfig-003-20260626 clang-22
x86_64 buildonly-randconfig-004-20260626 gcc-14
x86_64 buildonly-randconfig-005-20260626 clang-22
x86_64 buildonly-randconfig-006-20260626 clang-22
x86_64 defconfig gcc-14
x86_64 randconfig-001-20260626 clang-22
x86_64 randconfig-002-20260626 gcc-14
x86_64 randconfig-003-20260626 clang-22
x86_64 randconfig-004-20260626 clang-22
x86_64 randconfig-005-20260626 gcc-13
x86_64 randconfig-006-20260626 clang-22
x86_64 randconfig-011-20260626 gcc-14
x86_64 randconfig-012-20260626 gcc-14
x86_64 randconfig-013-20260626 clang-22
x86_64 randconfig-014-20260626 gcc-14
x86_64 randconfig-015-20260626 gcc-14
x86_64 randconfig-016-20260626 gcc-14
x86_64 randconfig-071-20260626 gcc-14
x86_64 randconfig-072-20260626 clang-22
x86_64 randconfig-073-20260626 gcc-14
x86_64 randconfig-074-20260626 gcc-14
x86_64 randconfig-075-20260626 gcc-14
x86_64 randconfig-076-20260626 gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig gcc-16.1.0
xtensa randconfig-001-20260626 gcc-12.5.0
xtensa randconfig-002-20260626 gcc-10.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl v3] ice: retry reading NVM if admin queue returns EBUSY
From: Robert Malz via Intel-wired-lan @ 2026-06-26 8:15 UTC (permalink / raw)
To: Przemek Kitszel; +Cc: anthony.l.nguyen, intel-wired-lan, Simon Horman, netdev
In-Reply-To: <CADcc-bwd2CcWJ1AFDm1GR1HBzo2OOh=Xr3moNS+-RVuai6yVBA@mail.gmail.com>
Hey Przemek,
I ran some tests and unfortunately, the following sentence from the
datasheet is true:
"For specific resources, such as Change Lock (0x0003) and Global Config Lock
(0x0004), this field is used by software to override the default timeout for the
operation, and also to specify the timeout used for this operation."
This means we can only change a default timeout for 0x0003 and 0x0004
but not for 0x0001 (NVM resource).
Whatever timeout I provide FW defaults to 0xB88
Input:
[ 2209.656758] ice 0000:31:00.0: CQ CMD: opcode 0x0008, flags 0x2000,
datalen 0x0000, retval 0x0000
[ 2209.656760] ice 0000:31:00.0: cookie (h,l) 0x00000000 0x00000000
[ 2209.656761] ice 0000:31:00.0: param (0,1) 0x00010001 0x00000BB9
Output:
[ 2209.656927] ice 0000:31:00.0: CQ CMD: opcode 0x0008, flags 0x2003,
datalen 0x0000, retval 0x0000
[ 2209.656929] ice 0000:31:00.0: cookie (h,l) 0x00000000 0x00000000
[ 2209.656931] ice 0000:31:00.0: param (0,1) 0x00010001 0x00000BB8
Correct me If I'm wrong, but the only way to properly handle it is to
ensure the resource is locked and released between every
ice_acquire_nvm call.
I'll start working on this.
Regards,
Robert
On Thu, Jun 25, 2026 at 12:14 PM Robert Malz <robert.malz@canonical.com> wrote:
>
> Hey Przemek,
> Thanks a lot for the feedback.
> I was sure that we use ICE_NVM_TIMEOUT (180s) as a timeout every time
> (ice_acquire_nvm) but your proposal made me rethink it a little.
> First of all, the datasheet for E810 specifies the timeout as: "As an
> input, the software might specify timeout longer than the default
> taken for this resource, and up to one minute."
> 180s is greater than one minute so I took a look into AQC logs:
> [ 110.698471] ice 0000:05:00.0: CQ CMD: opcode 0x0008, flags 0x2000,
> datalen 0x0000, retval 0x0000
> [ 110.698474] ice 0000:05:00.0: cookie (h,l) 0x00000000 0x00000000
> [ 110.698477] ice 0000:05:00.0: param (0,1) 0x00010001 0x0002BF20
> [ 110.698480] ice 0000:05:00.0: addr (h,l) 0x00000000 0x00000000
> [ 110.698645] ice 0000:05:00.0: ATQ: desc and buffer writeback:
> [ 110.698648] ice 0000:05:00.0: CQ CMD: opcode 0x0008, flags 0x2003,
> datalen 0x0000, retval 0x0000
> [ 110.698651] ice 0000:05:00.0: cookie (h,l) 0x00000000 0x00000000
> [ 110.698654] ice 0000:05:00.0: param (0,1) 0x00010001 0x00000BB8
> [ 110.698657] ice 0000:05:00.0: addr (h,l) 0x00000000 0x00000000
> Based on the above, the driver requested a 0x0002BF20 timeout (180 000
> ms) but the FW returned only 0x00000BB8 (3s).
> I'm assuming this is expected behavior since the maximum timeout for
> NVM read should be 60,000 ms.
>
> If changing the timeout requested by the driver to 60s for read ops is
> handled correctly by the FW and the FW respects that lock, the retry
> patch submitted in this email thread might not be required at all.
> Let me quickly prepare a new patch and test it. I'll update this
> thread once I have a results.
>
> Regards,
> Robert
>
>
> On Thu, Jun 25, 2026 at 9:51 AM Przemek Kitszel
> <przemyslaw.kitszel@intel.com> wrote:
> >
> > >> This is an AI-generated review of your patch. The human sending this
> >
> >
> > >> [Severity: Low]
> > >> Does this check allow an extra retry execution? Since retry_cnt starts at 0,
> > >> using a strictly greater-than check allows the loop to retry 4 times
> > >> (5 total executions) instead of the 3 executions intended by
> > >> ICE_SQ_SEND_MAX_EXECUTE.
> > >>
> > >>> + break;
> > >>> + ice_debug(hw, ICE_DBG_NVM,
> > >>> + "NVM read EBUSY error, retry %d\n",
> > >>> + retry_cnt + 1);
> > >>> + last_cmd = false;
> > >>> + ice_release_nvm(hw);
> > >>> + msleep(ICE_SQ_SEND_DELAY_TIME_MS);
> > >>
> > > The review is correct that this allows one extra execution. However, I
> > > intentionally kept this verbatim from the OOT driver (1.15.4) to
> >
> > This OOT change was made entirely by Grzegorz, for E825C. Would be great
> > to acknowledge his authorship (+ SoB ofc, below).
> > Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
> >
> > What was the platform that you have encountered the bug on?
> >
> > > retain the significant test exposure it has there. The absolute worst
> > > case is one harmless extra retry before giving up. If you strongly
> > > prefer strict adherence to ICE_SQ_SEND_MAX_EXECUTE, I can update the
> > > condition in a v4.
> >
> > Please update (to have one attempt less).
> >
> > >
> > >> [Severity: High]
> > >> Does dropping the NVM lock here violate the caller's assumption of mutual
> > >> exclusion?
> > >>
> > >> Callers of ice_read_flat_nvm() typically acquire the NVM lock beforehand to
> > >> ensure an atomic read of multiple sectors without interleaved writes. By
> > >> explicitly dropping the lock during the msleep() window, another thread, VF,
> > >> or PF could acquire the NVM lock and modify the NVM before the read resumes,
> > >> potentially resulting in reading torn or inconsistent NVM data.
> > >>
> > >>> + status = ice_acquire_nvm(hw, ICE_RES_READ);
> > >>> + if (status)
> > >>> + break;
> > >>
> > >
> > > I don't think this is an issue. The NVM resource (req_res 0x0008) is
> > > an ownership lease, not a content snapshot. The FW grants it with a
> > > hold timeout (see the timeout field handling in ice_aq_req_res). It
> > > never guaranteed a point-in-time view of the flash.
> > > Very similar behavior already exists in ice_devlink_nvm_snapshot(),
> > > which reads the NVM in chunks via ice_read_flat_nvm() and deliberately
> > > acquires/releases the lock between chunks (with a comment explaining
> > > the FW reclaim).
> > > Additionally, the lock is only dropped on the failure path, where
> > > neither bytes_read nor offset have been advanced. The driver simply
> > > re-reads the failed chunk after re-acquiring. So no data that is
> > > returned to the caller is committed across the drop window.
> > > Overall the lock drop does not weaken any guarantee callers actually
> > > have. If we wanted to introduce a true snapshot guarantee, that would
> > > probably require different approach and separate patch.
> > >
> > >
> > >> [Severity: High]
> > >> Can this lead to an unbalanced NVM resource lock release and potential data
> > >> corruption?
> > >>
> > >> If ice_acquire_nvm() fails here, the loop breaks and returns an error with the
> > >> lock currently unheld. However, callers like ice_read_flash_module() are
> > >> unaware of this internal lock state change and will unconditionally call
> > >> ice_release_nvm() upon failure:
> > >>
> > >> drivers/net/ethernet/intel/ice/ice_nvm.c:ice_read_flash_module() {
> > >> status = ice_acquire_nvm(hw, ICE_RES_READ);
> > >> if (status)
> > >> return status;
> > >>
> > >> status = ice_read_flat_nvm(hw, start + offset, &length, data, false);
> > >>
> > >> ice_release_nvm(hw);
> > >> ...
> > >>
> > >> Because firmware tracks resource locks per-PF rather than per-OS-thread, this
> > >> errant second release could forcefully strip the lock from another thread on
> > >> the same PF that successfully acquired it, exposing the NVM to concurrent
> > >> modification.
> > >>
> > >
> > > Agreed, this might be a real bug, and the one of the three I think is
> > > worth investigating.
> > > If ice_acquire_nvm() fails after the drop, ice_read_flat_nvm() returns
> > > with the lock unheld while callers unconditionally call
> > > ice_release_nvm(), so a stray release is issued.
> > >
> > > On probability, though, the window is very small. Reaching it requires
> > > sustained EBUSY across the retry budget plus a failed re-acquire
> > > (which itself polls up to ICE_NVM_TIMEOUT), and concurrently another
> > > requester taking the lock. Most reads happen during init (ice_probe,
> > > and reset/rebuild via ice_init_nvm), and NVM writes only happen on an
> > > already initialized driver. The devlink/ethtool nvm_read paths are
> > > also exposed, but hitting this race would require precise timing
> > > against a concurrent NVM owner on the device.
> > >
> > > I'd prefer to keep the scope of this patch limited to the EBUSY retry
> > > path and not take on the unbalanced-release fix here. A proper fix
> > > should change the lock-ownership contract of ice_read_flat_nvm() (on
> > > error, the lock must be released by ice_read_flat_nvm(), callers
> > > release only on success) and update all callers. Code change sould be
> > > simple for all callers but ice_discover_flash_size(), it intentionally
> > > holds one lease across a read loop and would need to re-acquire after
> > > each expected boundary failure.
> > >
> > > Given how small the original window is, I'd rather not trade tested
> > > OOT behavior for the risk of a complex unbalanced NVM lock fix. I
> > > actually have a patch mostly ready that fixes the lock-ownership
> > > contract, but I really don't like it. It changes the design of
> > > ice_read_flat_nvm(), making it less intuitive for callers. More
> > > importantly, I just don't have the resources or test coverage right
> > > now to properly verify such change.
> > >
> > > However, I can modify the failure path for ice_acquire_nvm inside
> > > ice_read_flat_nvm. Instead of bailing out immediately, we can just
> > > retry it within the existing retry budget. In this case, the
> > > probability of leaving ice_read_flat_nvm without holding the lock is
> > > reduced even further without needing a refactor.
> > >
> > > Please let me know what you think about my thought process on this.
> >
> > I think that both AI-reported issues against the lock are valid
> > concerns.
> >
> > I think that sleep was the actual fix, and re-locking were merely
> > a necessity due to their expiration (as you said).
> >
> > A proper fix would be to just increase lock-timeout to accommodate all
> > attempts (and still do the retries&sleep, but without unlocking).
> >
> >
> > >
> > >
> > >
> > >>> + retry_cnt++;
> > >>> + } else {
> > >>> + bytes_read += read_size;
> > >>> + offset += read_size;
> > >>> + retry_cnt = 0;
> > >>> + }
> > >>> } while (!last_cmd);
> > >>>
> > >>> *length = bytes_read;
> > >
> > > Thanks,
> > > Robert
> >
^ permalink raw reply
* [Intel-wired-lan] [tnguy-net-queue:200GbE] BUILD SUCCESS b78f348d4c4d862b1ad232f30c818f3ec8b97efb
From: kernel test robot @ 2026-06-26 7:04 UTC (permalink / raw)
To: Intel Wired LAN
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git 200GbE
branch HEAD: b78f348d4c4d862b1ad232f30c818f3ec8b97efb Merge branch 'net-hns3-fix-configuration-deadlocks-and-refactor-link-setup'
elapsed time: 723m
configs tested: 290
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001 gcc-16.1.0
arc randconfig-001-20260626 gcc-13.4.0
arc randconfig-001-20260626 gcc-16.1.0
arc randconfig-002 gcc-16.1.0
arc randconfig-002-20260626 gcc-13.4.0
arc randconfig-002-20260626 gcc-16.1.0
arm allnoconfig clang-17
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm allyesconfig gcc-16.1.0
arm defconfig clang-23
arm defconfig gcc-16.1.0
arm mxs_defconfig clang-17
arm randconfig-001 gcc-16.1.0
arm randconfig-001-20260626 gcc-13.4.0
arm randconfig-001-20260626 gcc-16.1.0
arm randconfig-002 gcc-16.1.0
arm randconfig-002-20260626 gcc-13.4.0
arm randconfig-002-20260626 gcc-16.1.0
arm randconfig-003 gcc-16.1.0
arm randconfig-003-20260626 gcc-13.4.0
arm randconfig-003-20260626 gcc-16.1.0
arm randconfig-004 gcc-16.1.0
arm randconfig-004-20260626 gcc-13.4.0
arm randconfig-004-20260626 gcc-16.1.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260626 gcc-8.5.0
arm64 randconfig-002-20260626 clang-17
arm64 randconfig-002-20260626 gcc-8.5.0
arm64 randconfig-003-20260626 gcc-15.2.0
arm64 randconfig-003-20260626 gcc-8.5.0
arm64 randconfig-004-20260626 gcc-13.4.0
arm64 randconfig-004-20260626 gcc-8.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260626 gcc-16.1.0
csky randconfig-001-20260626 gcc-8.5.0
csky randconfig-002-20260626 gcc-16.1.0
csky randconfig-002-20260626 gcc-8.5.0
hexagon allmodconfig clang-23
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-16.1.0
hexagon defconfig clang-23
hexagon defconfig gcc-16.1.0
hexagon randconfig-001-20260626 clang-23
hexagon randconfig-001-20260626 gcc-11.5.0
hexagon randconfig-002-20260626 clang-17
hexagon randconfig-002-20260626 gcc-11.5.0
i386 allmodconfig clang-22
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001 gcc-14
i386 buildonly-randconfig-001-20260626 gcc-14
i386 buildonly-randconfig-002 gcc-14
i386 buildonly-randconfig-002-20260626 gcc-14
i386 buildonly-randconfig-003 gcc-14
i386 buildonly-randconfig-003-20260626 gcc-14
i386 buildonly-randconfig-004 gcc-14
i386 buildonly-randconfig-004-20260626 gcc-12
i386 buildonly-randconfig-004-20260626 gcc-14
i386 buildonly-randconfig-005 gcc-14
i386 buildonly-randconfig-005-20260626 gcc-14
i386 buildonly-randconfig-006 gcc-14
i386 buildonly-randconfig-006-20260626 gcc-14
i386 defconfig clang-22
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260626 clang-22
i386 randconfig-001-20260626 gcc-14
i386 randconfig-002-20260626 gcc-14
i386 randconfig-003-20260626 clang-22
i386 randconfig-003-20260626 gcc-14
i386 randconfig-004-20260626 clang-22
i386 randconfig-004-20260626 gcc-14
i386 randconfig-005-20260626 gcc-14
i386 randconfig-006-20260626 gcc-14
i386 randconfig-007-20260626 gcc-14
i386 randconfig-011 gcc-14
i386 randconfig-011-20260626 gcc-14
i386 randconfig-012 gcc-14
i386 randconfig-012-20260626 clang-22
i386 randconfig-012-20260626 gcc-14
i386 randconfig-013 gcc-14
i386 randconfig-013-20260626 clang-22
i386 randconfig-013-20260626 gcc-14
i386 randconfig-014 gcc-14
i386 randconfig-014-20260626 gcc-14
i386 randconfig-015 gcc-14
i386 randconfig-015-20260626 gcc-14
i386 randconfig-016 gcc-14
i386 randconfig-016-20260626 clang-22
i386 randconfig-016-20260626 gcc-14
i386 randconfig-017 gcc-14
i386 randconfig-017-20260626 clang-22
i386 randconfig-017-20260626 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-20
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001-20260626 gcc-11.5.0
loongarch randconfig-001-20260626 gcc-16.1.0
loongarch randconfig-002-20260626 clang-18
loongarch randconfig-002-20260626 gcc-11.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k allyesconfig gcc-16.1.0
m68k defconfig clang-23
m68k defconfig gcc-16.1.0
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
microblaze defconfig gcc-16.1.0
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips loongson2k_defconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20260626 gcc-11.5.0
nios2 randconfig-002-20260626 gcc-11.5.0
nios2 randconfig-002-20260626 gcc-8.5.0
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-17
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260626 gcc-8.5.0
parisc randconfig-002-20260626 gcc-12.5.0
parisc randconfig-002-20260626 gcc-8.5.0
parisc64 defconfig clang-23
parisc64 defconfig gcc-16.1.0
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
powerpc ep88xc_defconfig gcc-16.1.0
powerpc motionpro_defconfig clang-23
powerpc randconfig-001-20260626 clang-23
powerpc randconfig-001-20260626 gcc-8.5.0
powerpc randconfig-002-20260626 gcc-11.5.0
powerpc randconfig-002-20260626 gcc-8.5.0
powerpc64 randconfig-001-20260626 clang-17
powerpc64 randconfig-001-20260626 gcc-8.5.0
powerpc64 randconfig-002-20260626 gcc-13.4.0
powerpc64 randconfig-002-20260626 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv nommu_k210_sdcard_defconfig gcc-16.1.0
riscv randconfig-001 clang-23
riscv randconfig-001-20260626 clang-23
riscv randconfig-001-20260626 gcc-11.5.0
riscv randconfig-002 clang-23
riscv randconfig-002-20260626 clang-23
s390 allmodconfig clang-17
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 clang-23
s390 randconfig-001-20260626 clang-23
s390 randconfig-002 clang-23
s390 randconfig-002-20260626 clang-23
s390 randconfig-002-20260626 gcc-8.5.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-17
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh defconfig gcc-16.1.0
sh randconfig-001 clang-23
sh randconfig-001-20260626 clang-23
sh randconfig-001-20260626 gcc-9.5.0
sh randconfig-002 clang-23
sh randconfig-002-20260626 clang-23
sh randconfig-002-20260626 gcc-16.1.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260626 gcc-12.5.0
sparc randconfig-002-20260626 gcc-12.5.0
sparc randconfig-002-20260626 gcc-8.5.0
sparc64 allmodconfig clang-20
sparc64 defconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260626 clang-20
sparc64 randconfig-001-20260626 gcc-12.5.0
sparc64 randconfig-002-20260626 clang-20
sparc64 randconfig-002-20260626 gcc-12.5.0
um allmodconfig clang-17
um allnoconfig clang-17
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-16.1.0
um defconfig clang-23
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260626 clang-18
um randconfig-001-20260626 gcc-12.5.0
um randconfig-002-20260626 clang-23
um randconfig-002-20260626 gcc-12.5.0
um x86_64_defconfig clang-23
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001-20260626 clang-22
x86_64 buildonly-randconfig-001-20260626 gcc-14
x86_64 buildonly-randconfig-002-20260626 gcc-14
x86_64 buildonly-randconfig-003-20260626 clang-22
x86_64 buildonly-randconfig-003-20260626 gcc-14
x86_64 buildonly-randconfig-004-20260626 gcc-14
x86_64 buildonly-randconfig-005-20260626 clang-22
x86_64 buildonly-randconfig-005-20260626 gcc-14
x86_64 buildonly-randconfig-006-20260626 clang-22
x86_64 buildonly-randconfig-006-20260626 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260626 clang-22
x86_64 randconfig-002-20260626 clang-22
x86_64 randconfig-002-20260626 gcc-14
x86_64 randconfig-003-20260626 clang-22
x86_64 randconfig-004-20260626 clang-22
x86_64 randconfig-005-20260626 clang-22
x86_64 randconfig-005-20260626 gcc-13
x86_64 randconfig-006-20260626 clang-22
x86_64 randconfig-011-20260626 gcc-14
x86_64 randconfig-012-20260626 gcc-14
x86_64 randconfig-013-20260626 clang-22
x86_64 randconfig-013-20260626 gcc-14
x86_64 randconfig-014-20260626 gcc-14
x86_64 randconfig-015-20260626 gcc-14
x86_64 randconfig-016-20260626 gcc-14
x86_64 randconfig-071 gcc-14
x86_64 randconfig-071-20260626 gcc-14
x86_64 randconfig-072 gcc-14
x86_64 randconfig-072-20260626 clang-22
x86_64 randconfig-072-20260626 gcc-14
x86_64 randconfig-073 gcc-14
x86_64 randconfig-073-20260626 gcc-14
x86_64 randconfig-074 gcc-14
x86_64 randconfig-074-20260626 gcc-14
x86_64 randconfig-075 gcc-14
x86_64 randconfig-075-20260626 gcc-14
x86_64 randconfig-076 gcc-14
x86_64 randconfig-076-20260626 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa allyesconfig gcc-16.1.0
xtensa randconfig-001-20260626 gcc-12.5.0
xtensa randconfig-002-20260626 gcc-10.5.0
xtensa randconfig-002-20260626 gcc-12.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH v4 net 2/3] i40e: fix potential UAF in i40e_vsi_setup()'s error path
From: Loktionov, Aleksandr @ 2026-06-26 6:45 UTC (permalink / raw)
To: Fijalkowski, Maciej, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Karlsson, Magnus, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, Kitszel, Przemyslaw,
Keller, Jacob E, Fijalkowski, Maciej
In-Reply-To: <20260625151431.1102838-3-maciej.fijalkowski@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Maciej Fijalkowski
> Sent: Thursday, June 25, 2026 5:15 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Karlsson, Magnus
> <magnus.karlsson@intel.com>; kuba@kernel.org; pabeni@redhat.com;
> horms@kernel.org; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>;
> Keller, Jacob E <jacob.e.keller@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>
> Subject: [Intel-wired-lan] [PATCH v4 net 2/3] i40e: fix potential UAF
> in i40e_vsi_setup()'s error path
>
> Sashiko pointed out an issue where error path in
> i40e_vsi_reinit_setup() released ring memory but then when freeing
> q_vectors, the rings mapped to q_vectors where touched which implies a
> regular use-after-free bug.
>
> Apparently i40e_vsi_setup() has the same problem, so swap the
> allocation and freeing order and fix the 13 year old bug.
>
> Fixes: 41c445ff0f48 ("i40e: main driver core")
> Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_main.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index 471fa7f7b643..4adc7b0fb2f4 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -14460,14 +14460,14 @@ struct i40e_vsi *i40e_vsi_setup(struct
> i40e_pf *pf, u8 type,
> fallthrough;
> case I40E_VSI_FDIR:
> /* set up vectors and rings if needed */
> - ret = i40e_vsi_setup_vectors(vsi);
> - if (ret)
> - goto err_msix;
> -
> ret = i40e_alloc_rings(vsi);
> if (ret)
> goto err_rings;
>
> + ret = i40e_vsi_setup_vectors(vsi);
> + if (ret)
> + goto err_qvec;
> +
> /* map all of the rings to the q_vectors */
> i40e_vsi_map_rings_to_vectors(vsi);
>
> @@ -14487,10 +14487,10 @@ struct i40e_vsi *i40e_vsi_setup(struct
> i40e_pf *pf, u8 type,
> return vsi;
>
> err_config:
> + i40e_vsi_free_q_vectors(vsi);
> +err_qvec:
> i40e_vsi_clear_rings(vsi);
> err_rings:
> - i40e_vsi_free_q_vectors(vsi);
> -err_msix:
> if (vsi->netdev_registered) {
> vsi->netdev_registered = false;
> unregister_netdev(vsi->netdev);
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH v4 net 1/3] i40e: unregister netdev before clearing VSI on reinit failure
From: Loktionov, Aleksandr @ 2026-06-26 6:45 UTC (permalink / raw)
To: Fijalkowski, Maciej, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Karlsson, Magnus, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, Kitszel, Przemyslaw,
Keller, Jacob E, Fijalkowski, Maciej
In-Reply-To: <20260625151431.1102838-2-maciej.fijalkowski@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Maciej Fijalkowski
> Sent: Thursday, June 25, 2026 5:14 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Karlsson, Magnus
> <magnus.karlsson@intel.com>; kuba@kernel.org; pabeni@redhat.com;
> horms@kernel.org; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>;
> Keller, Jacob E <jacob.e.keller@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>
> Subject: [Intel-wired-lan] [PATCH v4 net 1/3] i40e: unregister netdev
> before clearing VSI on reinit failure
>
> i40e_vsi_reinit_setup() tears down the existing VSI queue/ring backing
> state before allocating replacement arrays and queue tracking. If one
> of these early allocations fails, the function jumps directly to
> err_vsi and calls i40e_vsi_clear().
>
> For a registered netdev, this frees the VSI while netdev_priv(netdev)-
> >vsi can still point at it, leaving the registered netdev with
> dangling private driver state.
>
> Split the error path so failures after destructive reinit teardown
> first unregister and free the netdev before clearing the VSI.
>
> 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 | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index a04683004a56..471fa7f7b643 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -14274,7 +14274,7 @@ static struct i40e_vsi
> *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
> i40e_set_num_rings_in_vsi(vsi);
> ret = i40e_vsi_alloc_arrays(vsi, false);
> if (ret)
> - goto err_vsi;
> + goto err_netdev;
>
> alloc_queue_pairs = vsi->alloc_queue_pairs *
> (i40e_enabled_xdp_vsi(vsi) ? 2 : 1); @@ -
> 14284,7 +14284,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_netdev;
> }
> vsi->base_queue = ret;
>
> @@ -14309,6 +14309,7 @@ static struct i40e_vsi
> *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
>
> err_rings:
> i40e_vsi_free_q_vectors(vsi);
> +err_netdev:
> if (vsi->netdev_registered) {
> vsi->netdev_registered = false;
> unregister_netdev(vsi->netdev);
> @@ -14318,7 +14319,6 @@ 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_vsi:
> i40e_vsi_clear(vsi);
> return NULL;
> }
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH] ice: propagate ETH56G deskew read errors
From: Loktionov, Aleksandr @ 2026-06-26 6:45 UTC (permalink / raw)
To: Pengpeng Hou, Nguyen, Anthony L, Kitszel, Przemyslaw
Cc: Andrew Lunn, davem@davemloft.net, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Richard Cochran, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260625030305.85304-1-pengpeng@iscas.ac.cn>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Pengpeng Hou
> Sent: Thursday, June 25, 2026 5:03 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>
> Cc: Andrew Lunn <andrew+netdev@lunn.ch>; davem@davemloft.net; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; Richard Cochran <richardcochran@gmail.com>;
> intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; pengpeng@iscas.ac.cn
> Subject: [Intel-wired-lan] [PATCH] ice: propagate ETH56G deskew read
> errors
>
> ice_ptp_calc_deskew_eth56g() returns a u32 deskew value, but it also
> returns the negative read_poll_timeout() error when the DESKEW valid
> bit never appears. That converts the negative error into a large
> unsigned deskew contribution, which can then be folded into the RX
> timestamp offset and programmed into hardware.
>
> Return the deskew value through an output parameter and propagate the
> read error from ice_phy_set_offsets_eth56g() instead of using it as
> offset data.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
I recommend to add Fixes: tag, and proper net or net-next in [PATCH ] to steer properly your fix.
With the best regards
Alex
> ---
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 27 +++++++++++++++-----
> -
> 1 file changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> index 8e5f97835954..bd2e31b816a8 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> @@ -1736,17 +1736,21 @@ static u32 ice_ptp_calc_bitslip_eth56g(struct
> ice_hw *hw, u8 port, u32 bs,
> * @ds: deskew multiplier
> * @rs: RS-FEC enabled
> * @spd: link speed
> + * @deskew: calculated deskew value
> *
> - * Return: calculated deskew value
> + * Return: 0 on success, negative error code otherwise
> */
> -static u32 ice_ptp_calc_deskew_eth56g(struct ice_hw *hw, u8 port, u32
> ds,
> - bool rs, enum ice_eth56g_link_spd
> spd)
> +static int ice_ptp_calc_deskew_eth56g(struct ice_hw *hw, u8 port, u32
> ds,
> + bool rs, enum ice_eth56g_link_spd
> spd,
> + u32 *deskew)
> {
> u32 deskew_i, deskew_f;
> int err;
>
> - if (!ds)
> + if (!ds) {
> + *deskew = 0;
> return 0;
> + }
>
> read_poll_timeout(ice_read_ptp_reg_eth56g, err,
> FIELD_GET(PHY_REG_DESKEW_0_VALID, deskew_i),
> 500, @@ -1766,7 +1770,9 @@ static u32
> ice_ptp_calc_deskew_eth56g(struct ice_hw *hw, u8 port, u32 ds,
> deskew_i = FIELD_PREP(ICE_ETH56G_MAC_CFG_RX_OFFSET_INT,
> deskew_i);
> /* Shift 3 fractional bits to the end of the integer part */
> deskew_f <<= ICE_ETH56G_MAC_CFG_FRAC_W -
> PHY_REG_DESKEW_0_RLEVEL_FRAC_W;
> - return mul_u32_u32_fx_q9(deskew_i | deskew_f, ds);
> + *deskew = mul_u32_u32_fx_q9(deskew_i | deskew_f, ds);
> +
> + return 0;
> }
>
> /**
> @@ -1789,6 +1795,7 @@ static int ice_phy_set_offsets_eth56g(struct
> ice_hw *hw, u8 port, {
> u32 rx_offset, tx_offset, bs_ds;
> bool onestep, sfd;
> + int err;
>
> onestep = hw->ptp.phy.eth56g.onestep_ena;
> sfd = hw->ptp.phy.eth56g.sfd_ena;
> @@ -1805,11 +1812,15 @@ static int ice_phy_set_offsets_eth56g(struct
> ice_hw *hw, u8 port,
> if (sfd)
> rx_offset = add_u32_u32_fx(rx_offset, cfg-
> >rx_offset.sfd);
>
> - if (spd < ICE_ETH56G_LNK_SPD_40G)
> + if (spd < ICE_ETH56G_LNK_SPD_40G) {
> bs_ds = ice_ptp_calc_bitslip_eth56g(hw, port, bs_ds, fc,
> rs,
> spd);
> - else
> - bs_ds = ice_ptp_calc_deskew_eth56g(hw, port, bs_ds, rs,
> spd);
> + } else {
> + err = ice_ptp_calc_deskew_eth56g(hw, port, bs_ds, rs,
> spd,
> + &bs_ds);
> + if (err)
> + return err;
> + }
> rx_offset = add_u32_u32_fx(rx_offset, bs_ds);
> rx_offset &= ICE_ETH56G_MAC_CFG_RX_OFFSET_INT |
> ICE_ETH56G_MAC_CFG_RX_OFFSET_FRAC;
> --
> 2.50.1 (Apple Git-155)
^ permalink raw reply
* Re: [Intel-wired-lan] [TEST] Weird RSS state on ice
From: Loktionov, Aleksandr @ 2026-06-26 5:51 UTC (permalink / raw)
To: Jakub Kicinski, Pielech, Adrian
Cc: Kitszel, Przemyslaw, netdev@vger.kernel.org,
intel-wired-lan@lists.osuosl.org
In-Reply-To: <20260625190625.0f5ffe01@kernel.org>
> -----Original Message-----
> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Friday, June 26, 2026 4:06 AM
> To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> Cc: Pielech, Adrian <adrian.pielech@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; netdev@vger.kernel.org; intel-wired-
> lan@lists.osuosl.org
> Subject: Re: [Intel-wired-lan] [TEST] Weird RSS state on ice
>
> On Thu, 25 Jun 2026 07:11:14 +0000 Loktionov, Aleksandr wrote:
> > The patchset didn't help?
> >
> > [PATCH iwl-next v5 2/2] ice: implement symmetric RSS hash
> > configuration
>
> Not sure, it's not in tree, and lore doesn't want to point me at it
> either. What I don't get is how we get into the bad state in the first
> place.
>
> Looking at other tests today I spotted that rss flow label test is
> also behaving oddly. Most of the time the first case fails and the
> second
> passes:
>
> test "rss-flow-label-py"
> group "selftests-drivers-net-hw"
> result "fail"
> link "https://netdev-ci-results.intel.com/ice-results/net-next-hw-
> 2026-06-26--00-00/ice-E810-XXV4/rss_flow_label.py/stdout"
> results
> 0
> test "rss-flow-label-test-rss-flow-label"
> result "fail"
> 1
> test "rss-flow-label-test-rss-flow-label-6only"
> result "pass"
>
>
> But every now and then they skip:
>
> ok 1 rss_flow_label.test_rss_flow_label # SKIP Device doesn't support
> Flow Label for UDP6 ok 2 rss_flow_label.test_rss_flow_label_6only #
> SKIP Device doesn't support Flow Label for UDP6
>
> test "rss-flow-label-py"
> group "selftests-drivers-net-hw"
> result "skip"
> link "https://netdev-ci-results.intel.com/ice-results/net-next-hw-
> 2026-06-25--16-00/ice-E810-XXV4/rss_flow_label.py/stdout"
> results
> 0
> test "rss-flow-label-test-rss-flow-label"
> result "skip"
> 1
> test "rss-flow-label-test-rss-flow-label-6only"
> result "skip"
>
>
> The devlink info is identical so it must be that the device is in
> unclean state sometimes?? Do y'all power cycle these machines between
> runs?
Good day, Jakub
I heard from @Pielech, Adrian that we experienced infrastructure issues, but reboots helped us. Please ask him about CI infrastructure.
About my v5 March 16 symmetric RSS fix, which worked for me, I've just resent it today, please bless it.
With the best regards
Alex
^ permalink raw reply
* [Intel-wired-lan] [PATCH iwl-next v5 2/2] ice: implement symmetric RSS hash configuration
From: Aleksandr Loktionov @ 2026-06-26 5:47 UTC (permalink / raw)
To: intel-wired-lan, anthony.l.nguyen, aleksandr.loktionov; +Cc: netdev
In-Reply-To: <20260626054730.1126969-1-aleksandr.loktionov@intel.com>
The driver advertises symmetric RSS support via supported_input_xfrm
but ice_set_rxfh() always programmed plain Toeplitz regardless of the
requested input_xfrm, making it impossible to actually enable symmetric
hashing.
Fix ice_set_rxfh() to honour rxfh->input_xfrm: program symmetric
Toeplitz (ICE_AQ_VSI_Q_OPT_RSS_HASH_SYM_TPLZ) when RXH_XFRM_SYM_XOR
is requested, revert to plain Toeplitz when the transform is cleared,
and skip the hardware write when the function has not changed.
Make ice_set_rss_vsi_ctx() non-static and export it so ice_set_rxfh()
can reprogram the VSI context directly. Change it to preserve
vsi->rss_hfunc across VSI reinitialisation instead of always resetting
to plain Toeplitz, which would silently undo any previously configured
symmetric hash function.
Fix ice_get_rxfh_fields() to report the hash fields actually programmed
in hardware. When the hardware hashes on only one half of an L3 or L4
pair, complete the pair in the reported bitmap to satisfy the kernel's
symmetry validator. For GTP flow types, report RXH_GTP_TEID honestly;
ethtool_rxfh_config_is_sym() now accepts TEID as an intrinsically
symmetric field (see preceding patch).
Tested with tools/testing/selftests/drivers/net/hw/rss_input_xfrm.py
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
drivers/net/ethernet/intel/ice/ice_ethtool.c | 40 ++++++++++++++++----
drivers/net/ethernet/intel/ice/ice_lib.c | 7 ++--
drivers/net/ethernet/intel/ice/ice_lib.h | 1 +
3 files changed, 37 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c
index c6bc29c..6ccfe36 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
@@ -3008,14 +3008,17 @@ ice_set_rxfh_fields(struct net_device *netdev,
return 0;
}
+#define ICE_RSS_L3_PAIR (RXH_IP_SRC | RXH_IP_DST)
+#define ICE_RSS_L4_PAIR (RXH_L4_B_0_1 | RXH_L4_B_2_3)
+
static int
ice_get_rxfh_fields(struct net_device *netdev, struct ethtool_rxfh_fields *nfc)
{
struct ice_netdev_priv *np = netdev_priv(netdev);
struct ice_vsi *vsi = np->vsi;
struct ice_pf *pf = vsi->back;
+ u64 l3, l4, hash_flds;
struct device *dev;
- u64 hash_flds;
bool symm;
u32 hdrs;
@@ -3067,6 +3070,13 @@ ice_get_rxfh_fields(struct net_device *netdev, struct ethtool_rxfh_fields *nfc)
hash_flds & ICE_FLOW_HASH_FLD_GTPU_DWN_TEID)
nfc->data |= (u64)RXH_GTP_TEID;
+ l3 = nfc->data & ICE_RSS_L3_PAIR;
+ l4 = nfc->data & ICE_RSS_L4_PAIR;
+ if (l3 && l3 != ICE_RSS_L3_PAIR)
+ nfc->data |= ICE_RSS_L3_PAIR;
+ if (l4 && l4 != ICE_RSS_L4_PAIR)
+ nfc->data |= ICE_RSS_L4_PAIR;
+
return 0;
}
@@ -3667,7 +3677,6 @@ ice_set_rxfh(struct net_device *netdev, struct ethtool_rxfh_param *rxfh,
struct netlink_ext_ack *extack)
{
struct ice_netdev_priv *np = netdev_priv(netdev);
- u8 hfunc = ICE_AQ_VSI_Q_OPT_RSS_HASH_TPLZ;
struct ice_vsi *vsi = np->vsi;
struct ice_pf *pf = vsi->back;
struct device *dev;
@@ -3689,13 +3698,28 @@ ice_set_rxfh(struct net_device *netdev, struct ethtool_rxfh_param *rxfh,
return -EOPNOTSUPP;
}
- /* Update the VSI's hash function */
- if (rxfh->input_xfrm & RXH_XFRM_SYM_XOR)
- hfunc = ICE_AQ_VSI_Q_OPT_RSS_HASH_SYM_TPLZ;
+ /* Handle RSS symmetric hash transformation */
+ if (rxfh->input_xfrm != RXH_XFRM_NO_CHANGE) {
+ u8 new_hfunc;
- err = ice_set_rss_hfunc(vsi, hfunc);
- if (err)
- return err;
+ if (rxfh->input_xfrm == RXH_XFRM_SYM_XOR)
+ new_hfunc = ICE_AQ_VSI_Q_OPT_RSS_HASH_SYM_TPLZ;
+ else if (!rxfh->input_xfrm)
+ new_hfunc = ICE_AQ_VSI_Q_OPT_RSS_HASH_TPLZ;
+ else
+ return -EOPNOTSUPP;
+
+ if (new_hfunc != vsi->rss_hfunc) {
+ err = ice_set_rss_hfunc(vsi, new_hfunc);
+ if (err) {
+ netdev_err(netdev, "Failed to set RSS hash function\n");
+ return err;
+ }
+ netdev_dbg(netdev, "RSS hash function: %sToeplitz\n",
+ new_hfunc == ICE_AQ_VSI_Q_OPT_RSS_HASH_SYM_TPLZ ?
+ "Symmetric " : "");
+ }
+ }
if (rxfh->key) {
if (!vsi->rss_hkey_user) {
diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
index d921269..5b1934b 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_lib.c
@@ -1155,7 +1155,7 @@ static void ice_set_fd_vsi_ctx(struct ice_vsi_ctx *ctxt, struct ice_vsi *vsi)
* @ctxt: the VSI context being set
* @vsi: the VSI being configured
*/
-static void ice_set_rss_vsi_ctx(struct ice_vsi_ctx *ctxt, struct ice_vsi *vsi)
+void ice_set_rss_vsi_ctx(struct ice_vsi_ctx *ctxt, struct ice_vsi *vsi)
{
u8 lut_type, hash_type;
struct device *dev;
@@ -1181,8 +1181,9 @@ static void ice_set_rss_vsi_ctx(struct ice_vsi_ctx *ctxt, struct ice_vsi *vsi)
return;
}
- hash_type = ICE_AQ_VSI_Q_OPT_RSS_HASH_TPLZ;
- vsi->rss_hfunc = hash_type;
+ if (!vsi->rss_hfunc)
+ vsi->rss_hfunc = ICE_AQ_VSI_Q_OPT_RSS_HASH_TPLZ;
+ hash_type = vsi->rss_hfunc;
ctxt->info.q_opt_rss =
FIELD_PREP(ICE_AQ_VSI_Q_OPT_RSS_LUT_M, lut_type) |
diff --git a/drivers/net/ethernet/intel/ice/ice_lib.h b/drivers/net/ethernet/intel/ice/ice_lib.h
index 49454d98..29ba335 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.h
+++ b/drivers/net/ethernet/intel/ice/ice_lib.h
@@ -46,6 +46,7 @@ void ice_vsi_delete(struct ice_vsi *vsi);
int ice_vsi_cfg_tc(struct ice_vsi *vsi, u8 ena_tc);
int ice_vsi_cfg_rss_lut_key(struct ice_vsi *vsi);
+void ice_set_rss_vsi_ctx(struct ice_vsi_ctx *ctxt, struct ice_vsi *vsi);
void ice_vsi_cfg_netdev_tc(struct ice_vsi *vsi, u8 ena_tc);
--
2.52.0
^ permalink raw reply related
* [Intel-wired-lan] [PATCH iwl-next v5 1/2] ethtool: treat RXH_GTP_TEID as intrinsically symmetric
From: Aleksandr Loktionov @ 2026-06-26 5:47 UTC (permalink / raw)
To: intel-wired-lan, anthony.l.nguyen, aleksandr.loktionov; +Cc: netdev
In-Reply-To: <20260626054730.1126969-1-aleksandr.loktionov@intel.com>
A GTP tunnel uses the same TEID value in both directions of a flow;
including TEID in the hash input does not break src/dst symmetry.
ethtool_rxfh_config_is_sym() currently rejects any hash field bitmap
that contains bits outside the four paired L3/L4 fields. This causes
drivers that hash GTP flows on TEID to fail the kernel's preflight
validation in ethtool_check_flow_types(), making it impossible for
those drivers to support symmetric-xor transforms at all.
Strip RXH_GTP_TEID from the bitmap before the paired-field check so
that drivers may honestly report TEID hashing without blocking the
configuration of symmetric transforms.
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
net/ethtool/common.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ethtool/common.c b/net/ethtool/common.c
index 5fae329..9a3fd76 100644
--- a/net/ethtool/common.c
+++ b/net/ethtool/common.c
@@ -911,6 +911,9 @@ int ethtool_rxfh_config_is_sym(u64 rxfh)
{
bool sym;
+ /* Strip TEID before checking - it carries no src/dst asymmetry */
+ rxfh &= ~RXH_GTP_TEID;
+
sym = rxfh == (rxfh & (RXH_IP_SRC | RXH_IP_DST |
RXH_L4_B_0_1 | RXH_L4_B_2_3));
sym &= !!(rxfh & RXH_IP_SRC) == !!(rxfh & RXH_IP_DST);
--
2.52.0
^ permalink raw reply related
* [Intel-wired-lan] [PATCH iwl-next v5 0/2] ice: implement symmetric RSS hash configuration
From: Aleksandr Loktionov @ 2026-06-26 5:47 UTC (permalink / raw)
To: intel-wired-lan, anthony.l.nguyen, aleksandr.loktionov; +Cc: netdev
The ice driver has advertised symmetric RSS support via
supported_input_xfrm since the capability was added, but ice_set_rxfh()
ignored the input_xfrm parameter entirely, so enabling symmetric hashing
had no actual effect.
This series fixes that. Patch 1 extends the ethtool core so that
drivers hashing GTP flows on TEID can report it honestly without
blocking symmetric-xor configuration. Patch 2 wires up the ice driver.
The need for patch 1 surfaced because GTP flow profiles in ice always
include TEID in the hash. ethtool_check_flow_types() calls
get_rxfh_fields() for every hashable flow type before allowing
symmetric-xor; ethtool_rxfh_config_is_sym() rejected any bitmap
containing RXH_GTP_TEID since it has no src/dst counterpart. TEID
is the same value in both tunnel directions, so this rejection is
incorrect: including it does not break symmetry.
Rather than hiding TEID from the reported fields (which would silently
misrepresent hardware behaviour), patch 1 fixes the validator, and
patch 2 reports TEID honestly.
Tested with tools/testing/selftests/drivers/net/hw/rss_input_xfrm.py
on an E810 card running kernel 6.19-rc8.
---
v4 -> v5:
- remove redundant (u64) type conversion
v3 -> v4:
- Drop the ICE_HASH_INVALID fallback in ice_get_rxfh_fields() that
fabricated default L3+L4 hash fields when no hardware RSS config
exists for a flow type; returning zero fields is more honest and
avoids misrepresenting hardware state
- Drop the companion "if (!l3 && !l4)" special case in the
pair-completion block; it was only necessary to cover the synthetic
defaults added by the fallback, which is now gone
- No functional change to ice_set_rxfh() or the ethtool core patch
v2 -> v3:
- Split into 2 patches: ethtool core fix separate from driver change
- Drop the RXH_GTP_TEID stripping workaround from the driver; instead
fix ethtool_rxfh_config_is_sym() to accept TEID as intrinsically
symmetric (patch 1)
- Fix ice_get_rxfh_fields(): the v2 unconditional assignment
"nfc->data = ICE_RSS_ALLOWED_FIELDS" clobbered fields set earlier in
the same function; replaced with pair-completion using |= so only
the missing half of a partial pair is filled in
- Remove ICE_RSS_ALLOWED_FIELDS define (no longer needed)
- Report RXH_GTP_TEID honestly for GTP flow types
v1 -> v2:
- Preserve valid symmetric RSS fields instead of overwriting nfc->data
unconditionally
Aleksandr Loktionov (2):
ethtool: treat RXH_GTP_TEID as intrinsically symmetric
ice: implement symmetric RSS hash configuration
drivers/net/ethernet/intel/ice/ice_ethtool.c | 40 +++++++++++++---
drivers/net/ethernet/intel/ice/ice_lib.c | 7 ++--
drivers/net/ethernet/intel/ice/ice_lib.h | 1 +
net/ethtool/common.c | 3 +++
4 files changed, 40 insertions(+), 11 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [Intel-wired-lan] [TEST] Weird RSS state on ice
From: Jakub Kicinski @ 2026-06-26 2:06 UTC (permalink / raw)
To: Loktionov, Aleksandr
Cc: Pielech, Adrian, Kitszel, Przemyslaw, netdev@vger.kernel.org,
intel-wired-lan@lists.osuosl.org
In-Reply-To: <DS4PPF7551E65529A34C04A73F4287C2B4EE5EC2@DS4PPF7551E6552.namprd11.prod.outlook.com>
On Thu, 25 Jun 2026 07:11:14 +0000 Loktionov, Aleksandr wrote:
> The patchset didn't help?
>
> [PATCH iwl-next v5 2/2] ice: implement symmetric RSS hash configuration
Not sure, it's not in tree, and lore doesn't want to point me at it
either. What I don't get is how we get into the bad state in the first
place.
Looking at other tests today I spotted that rss flow label test is also
behaving oddly. Most of the time the first case fails and the second
passes:
test "rss-flow-label-py"
group "selftests-drivers-net-hw"
result "fail"
link "https://netdev-ci-results.intel.com/ice-results/net-next-hw-2026-06-26--00-00/ice-E810-XXV4/rss_flow_label.py/stdout"
results
0
test "rss-flow-label-test-rss-flow-label"
result "fail"
1
test "rss-flow-label-test-rss-flow-label-6only"
result "pass"
But every now and then they skip:
ok 1 rss_flow_label.test_rss_flow_label # SKIP Device doesn't support Flow Label for UDP6
ok 2 rss_flow_label.test_rss_flow_label_6only # SKIP Device doesn't support Flow Label for UDP6
test "rss-flow-label-py"
group "selftests-drivers-net-hw"
result "skip"
link "https://netdev-ci-results.intel.com/ice-results/net-next-hw-2026-06-25--16-00/ice-E810-XXV4/rss_flow_label.py/stdout"
results
0
test "rss-flow-label-test-rss-flow-label"
result "skip"
1
test "rss-flow-label-test-rss-flow-label-6only"
result "skip"
The devlink info is identical so it must be that the device
is in unclean state sometimes?? Do y'all power cycle these
machines between runs?
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net v7 2/4] i40e: skip unnecessary VF reset when setting trust
From: Przemek Kitszel @ 2026-06-25 12:17 UTC (permalink / raw)
To: Simon Horman, jtornosm
Cc: netdev, intel-wired-lan, aleksandr.loktionov, jacob.e.keller,
anthony.l.nguyen, davem, edumazet, kuba, pabeni
In-Reply-To: <20260624163050.1145761-1-horms@kernel.org>
On 6/24/26 18:30, 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.
> Full review at: https://netdev-ai.bots.linux.dev/sashiko/
> ---
> i40e: skip unnecessary VF reset when setting trust
>
> This patch avoids the ~10 second VF reset delay on trust changes by
> flipping the I40E_VIRTCHNL_VF_CAP_PRIVILEGE bit directly, and only
> resorting to a full reset when revoking trust from a VF that has
> advanced features (ADQ, cloud filters, UC/MC promisc) configured.
>
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
>> index a26c3d47ec15..0cc434b26eb8 100644
>> --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
>> +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
>> @@ -4987,19 +5004,20 @@ 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);
>> + /* Reset only if revoking trust and VF has advanced features configured */
>> + if (!setting &&
>> + (vf->adq_enabled || vf->num_cloud_filters > 0 ||
>> + test_bit(I40E_VF_STATE_UC_PROMISC, &vf->vf_states) ||
>> + test_bit(I40E_VF_STATE_MC_PROMISC, &vf->vf_states))) {
>
> [High]
> Does this revoke-trust heuristic miss MAC/VLAN filters that were only
> installable while the VF was trusted?
No.
>
> A trusted VF is allowed to add many more MAC addresses than
> I40E_VC_MAX_MAC_ADDR_PER_VF (i40e_check_vf_permission() uses
> I40E_VC_MAX_MACVLAN_PER_TRUSTED_VF) and more than I40E_VC_MAX_VLAN_PER_VF
> VLANs. These quotas are enforced only at add-time.
>
> The previous always-reset path went through i40e_vc_reset_vf() ->
> i40e_cleanup_reset_vf() -> i40e_free_vf_res() -> i40e_vsi_release(),
> which destroyed the VSI and its mac_filter_hash, and reset
> vf->num_vlan = 0.
Current "reset only on revoke" does exactly the same.
>
> The new fast path only flips the PRIVILEGE bit, leaving any
NOPE.
New "fast path" only *TESTS* the PRIVILEGE bit,
it does not "clear" it in fast path.
This is just negated/wrong/inverted logic on AI side
^ permalink raw reply
* [Intel-wired-lan] [PATCH] ice: propagate ETH56G deskew read errors
From: Pengpeng Hou @ 2026-06-25 3:03 UTC (permalink / raw)
To: Tony Nguyen, Przemek Kitszel
Cc: Andrew Lunn, davem, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Richard Cochran, intel-wired-lan, netdev, linux-kernel, pengpeng
ice_ptp_calc_deskew_eth56g() returns a u32 deskew value, but it also
returns the negative read_poll_timeout() error when the DESKEW valid bit
never appears. That converts the negative error into a large unsigned
deskew contribution, which can then be folded into the RX timestamp
offset and programmed into hardware.
Return the deskew value through an output parameter and propagate the
read error from ice_phy_set_offsets_eth56g() instead of using it as
offset data.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 27 +++++++++++++++------
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
index 8e5f97835954..bd2e31b816a8 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
@@ -1736,17 +1736,21 @@ static u32 ice_ptp_calc_bitslip_eth56g(struct ice_hw *hw, u8 port, u32 bs,
* @ds: deskew multiplier
* @rs: RS-FEC enabled
* @spd: link speed
+ * @deskew: calculated deskew value
*
- * Return: calculated deskew value
+ * Return: 0 on success, negative error code otherwise
*/
-static u32 ice_ptp_calc_deskew_eth56g(struct ice_hw *hw, u8 port, u32 ds,
- bool rs, enum ice_eth56g_link_spd spd)
+static int ice_ptp_calc_deskew_eth56g(struct ice_hw *hw, u8 port, u32 ds,
+ bool rs, enum ice_eth56g_link_spd spd,
+ u32 *deskew)
{
u32 deskew_i, deskew_f;
int err;
- if (!ds)
+ if (!ds) {
+ *deskew = 0;
return 0;
+ }
read_poll_timeout(ice_read_ptp_reg_eth56g, err,
FIELD_GET(PHY_REG_DESKEW_0_VALID, deskew_i), 500,
@@ -1766,7 +1770,9 @@ static u32 ice_ptp_calc_deskew_eth56g(struct ice_hw *hw, u8 port, u32 ds,
deskew_i = FIELD_PREP(ICE_ETH56G_MAC_CFG_RX_OFFSET_INT, deskew_i);
/* Shift 3 fractional bits to the end of the integer part */
deskew_f <<= ICE_ETH56G_MAC_CFG_FRAC_W - PHY_REG_DESKEW_0_RLEVEL_FRAC_W;
- return mul_u32_u32_fx_q9(deskew_i | deskew_f, ds);
+ *deskew = mul_u32_u32_fx_q9(deskew_i | deskew_f, ds);
+
+ return 0;
}
/**
@@ -1789,6 +1795,7 @@ static int ice_phy_set_offsets_eth56g(struct ice_hw *hw, u8 port,
{
u32 rx_offset, tx_offset, bs_ds;
bool onestep, sfd;
+ int err;
onestep = hw->ptp.phy.eth56g.onestep_ena;
sfd = hw->ptp.phy.eth56g.sfd_ena;
@@ -1805,11 +1812,15 @@ static int ice_phy_set_offsets_eth56g(struct ice_hw *hw, u8 port,
if (sfd)
rx_offset = add_u32_u32_fx(rx_offset, cfg->rx_offset.sfd);
- if (spd < ICE_ETH56G_LNK_SPD_40G)
+ if (spd < ICE_ETH56G_LNK_SPD_40G) {
bs_ds = ice_ptp_calc_bitslip_eth56g(hw, port, bs_ds, fc, rs,
spd);
- else
- bs_ds = ice_ptp_calc_deskew_eth56g(hw, port, bs_ds, rs, spd);
+ } else {
+ err = ice_ptp_calc_deskew_eth56g(hw, port, bs_ds, rs, spd,
+ &bs_ds);
+ if (err)
+ return err;
+ }
rx_offset = add_u32_u32_fx(rx_offset, bs_ds);
rx_offset &= ICE_ETH56G_MAC_CFG_RX_OFFSET_INT |
ICE_ETH56G_MAC_CFG_RX_OFFSET_FRAC;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [Intel-wired-lan] [PATCH v4 net 3/3] i40e: keep q_vectors array in sync with channel count changes
From: Maciej Fijalkowski @ 2026-06-25 15:14 UTC (permalink / raw)
To: intel-wired-lan
Cc: netdev, magnus.karlsson, kuba, pabeni, horms, przemyslaw.kitszel,
jacob.e.keller, Maciej Fijalkowski
In-Reply-To: <20260625151431.1102838-1-maciej.fijalkowski@intel.com>
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 | 60 +++++++++++++--------
1 file changed, 37 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 4adc7b0fb2f4..c017217a1bc3 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -11406,10 +11406,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(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);
@@ -11417,7 +11421,7 @@ 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 = clamp(qps, 1, pf->num_lan_msix);
else
vsi->num_q_vectors = 1;
@@ -11469,12 +11473,11 @@ static int i40e_set_num_rings_in_vsi(struct i40e_vsi *vsi)
/**
* i40e_vsi_alloc_arrays - Allocate queue and vector pointer arrays for the vsi
* @vsi: VSI pointer
- * @alloc_qvectors: a bool to specify if q_vectors need to be allocated.
*
* On error: returns error code (negative)
* On success: returns 0
**/
-static int i40e_vsi_alloc_arrays(struct i40e_vsi *vsi, bool alloc_qvectors)
+static int i40e_vsi_alloc_arrays(struct i40e_vsi *vsi)
{
struct i40e_ring **next_rings;
int size;
@@ -11493,19 +11496,18 @@ static int i40e_vsi_alloc_arrays(struct i40e_vsi *vsi, bool alloc_qvectors)
}
vsi->rx_rings = next_rings;
- if (alloc_qvectors) {
- /* allocate memory for q_vector pointers */
- size = sizeof(struct i40e_q_vector *) * vsi->num_q_vectors;
- vsi->q_vectors = kzalloc(size, GFP_KERNEL);
- if (!vsi->q_vectors) {
- ret = -ENOMEM;
- goto err_vectors;
- }
+ /* allocate memory for q_vector pointers */
+ size = sizeof(struct i40e_q_vector *) * vsi->num_q_vectors;
+ vsi->q_vectors = kzalloc(size, GFP_KERNEL);
+ if (!vsi->q_vectors) {
+ ret = -ENOMEM;
+ goto err_vectors;
}
return ret;
err_vectors:
kfree(vsi->tx_rings);
+ vsi->tx_rings = NULL;
return ret;
}
@@ -11578,7 +11580,7 @@ static int i40e_vsi_mem_alloc(struct i40e_pf *pf, enum i40e_vsi_type type)
if (ret)
goto err_rings;
- ret = i40e_vsi_alloc_arrays(vsi, true);
+ ret = i40e_vsi_alloc_arrays(vsi);
if (ret)
goto err_rings;
@@ -11603,18 +11605,15 @@ static int i40e_vsi_mem_alloc(struct i40e_pf *pf, enum i40e_vsi_type type)
/**
* i40e_vsi_free_arrays - Free queue and vector pointer arrays for the VSI
* @vsi: VSI pointer
- * @free_qvectors: a bool to specify if q_vectors need to be freed.
*
* On error: returns error code (negative)
* On success: returns 0
**/
-static void i40e_vsi_free_arrays(struct i40e_vsi *vsi, bool free_qvectors)
+static void i40e_vsi_free_arrays(struct i40e_vsi *vsi)
{
/* free the ring and vector containers */
- if (free_qvectors) {
- kfree(vsi->q_vectors);
- vsi->q_vectors = NULL;
- }
+ kfree(vsi->q_vectors);
+ vsi->q_vectors = NULL;
kfree(vsi->tx_rings);
vsi->tx_rings = NULL;
vsi->rx_rings = NULL;
@@ -11674,7 +11673,7 @@ static int i40e_vsi_clear(struct i40e_vsi *vsi)
i40e_put_lump(pf->irq_pile, vsi->base_vector, vsi->idx);
bitmap_free(vsi->af_xdp_zc_qps);
- i40e_vsi_free_arrays(vsi, true);
+ i40e_vsi_free_arrays(vsi);
i40e_clear_rss_config_user(vsi);
pf->vsi[vsi->idx] = NULL;
@@ -12046,7 +12045,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;
@@ -14267,12 +14267,26 @@ 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_free_q_vectors(vsi);
i40e_vsi_clear_rings(vsi);
+ i40e_vsi_free_arrays(vsi);
- i40e_vsi_free_arrays(vsi, false);
i40e_set_num_rings_in_vsi(vsi);
- ret = i40e_vsi_alloc_arrays(vsi, false);
+ ret = i40e_vsi_alloc_arrays(vsi);
+ if (ret)
+ goto err_netdev;
+
+ /* 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_netdev;
@@ -14284,7 +14298,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_netdev;
+ goto err_rings;
}
vsi->base_queue = ret;
--
2.43.0
^ permalink raw reply related
* [Intel-wired-lan] [PATCH v4 net 2/3] i40e: fix potential UAF in i40e_vsi_setup()'s error path
From: Maciej Fijalkowski @ 2026-06-25 15:14 UTC (permalink / raw)
To: intel-wired-lan
Cc: netdev, magnus.karlsson, kuba, pabeni, horms, przemyslaw.kitszel,
jacob.e.keller, Maciej Fijalkowski
In-Reply-To: <20260625151431.1102838-1-maciej.fijalkowski@intel.com>
Sashiko pointed out an issue where error path in i40e_vsi_reinit_setup()
released ring memory but then when freeing q_vectors, the rings mapped
to q_vectors where touched which implies a regular use-after-free bug.
Apparently i40e_vsi_setup() has the same problem, so swap the allocation
and freeing order and fix the 13 year old bug.
Fixes: 41c445ff0f48 ("i40e: main driver core")
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 471fa7f7b643..4adc7b0fb2f4 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -14460,14 +14460,14 @@ struct i40e_vsi *i40e_vsi_setup(struct i40e_pf *pf, u8 type,
fallthrough;
case I40E_VSI_FDIR:
/* set up vectors and rings if needed */
- ret = i40e_vsi_setup_vectors(vsi);
- if (ret)
- goto err_msix;
-
ret = i40e_alloc_rings(vsi);
if (ret)
goto err_rings;
+ ret = i40e_vsi_setup_vectors(vsi);
+ if (ret)
+ goto err_qvec;
+
/* map all of the rings to the q_vectors */
i40e_vsi_map_rings_to_vectors(vsi);
@@ -14487,10 +14487,10 @@ struct i40e_vsi *i40e_vsi_setup(struct i40e_pf *pf, u8 type,
return vsi;
err_config:
+ i40e_vsi_free_q_vectors(vsi);
+err_qvec:
i40e_vsi_clear_rings(vsi);
err_rings:
- i40e_vsi_free_q_vectors(vsi);
-err_msix:
if (vsi->netdev_registered) {
vsi->netdev_registered = false;
unregister_netdev(vsi->netdev);
--
2.43.0
^ permalink raw reply related
* [Intel-wired-lan] [PATCH v4 net 1/3] i40e: unregister netdev before clearing VSI on reinit failure
From: Maciej Fijalkowski @ 2026-06-25 15:14 UTC (permalink / raw)
To: intel-wired-lan
Cc: netdev, magnus.karlsson, kuba, pabeni, horms, przemyslaw.kitszel,
jacob.e.keller, Maciej Fijalkowski
In-Reply-To: <20260625151431.1102838-1-maciej.fijalkowski@intel.com>
i40e_vsi_reinit_setup() tears down the existing VSI queue/ring backing
state before allocating replacement arrays and queue tracking. If one of
these early allocations fails, the function jumps directly to err_vsi
and calls i40e_vsi_clear().
For a registered netdev, this frees the VSI while
netdev_priv(netdev)->vsi can still point at it, leaving the registered
netdev with dangling private driver state.
Split the error path so failures after destructive reinit teardown first
unregister and free the netdev before clearing the VSI.
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 | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index a04683004a56..471fa7f7b643 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -14274,7 +14274,7 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
i40e_set_num_rings_in_vsi(vsi);
ret = i40e_vsi_alloc_arrays(vsi, false);
if (ret)
- goto err_vsi;
+ goto err_netdev;
alloc_queue_pairs = vsi->alloc_queue_pairs *
(i40e_enabled_xdp_vsi(vsi) ? 2 : 1);
@@ -14284,7 +14284,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_netdev;
}
vsi->base_queue = ret;
@@ -14309,6 +14309,7 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
err_rings:
i40e_vsi_free_q_vectors(vsi);
+err_netdev:
if (vsi->netdev_registered) {
vsi->netdev_registered = false;
unregister_netdev(vsi->netdev);
@@ -14318,7 +14319,6 @@ 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_vsi:
i40e_vsi_clear(vsi);
return NULL;
}
--
2.43.0
^ permalink raw reply related
* [Intel-wired-lan] [PATCH v4 net 0/3] i40e: re-init and UAF fixes
From: Maciej Fijalkowski @ 2026-06-25 15:14 UTC (permalink / raw)
To: intel-wired-lan
Cc: netdev, magnus.karlsson, kuba, pabeni, horms, przemyslaw.kitszel,
jacob.e.keller, Maciej Fijalkowski
v4:
- add preceding patch that fixes a case when some of re-init allocations
failed and we missed de-registering netdev at failure path
- pull out i40e_vsi_setup() changes onto separate patch
v3:
- address UAF when ring arrays were freed before q_vector's ring
containers (Sashiko, Jacob)
- remove bool params from alloc/free array routines (Simon)
v2:
- NULL vsi->tx_rings in i40e_vsi_alloc_arrays() (Sashiko)
Maciej Fijalkowski (3):
i40e: unregister netdev before clearing VSI on reinit failure
i40e: fix potential UAF in i40e_vsi_setup()'s error path
i40e: keep q_vectors array in sync with channel count changes
drivers/net/ethernet/intel/i40e/i40e_main.c | 76 ++++++++++++---------
1 file changed, 45 insertions(+), 31 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net] igc: Fix RX HW timestamp reporting when NET_RX_BUSY_POLL is disabled
From: Marcin Szycik @ 2026-06-25 11:07 UTC (permalink / raw)
To: Florian Bezdeka, Kwapulinski, Piotr, Ding Meng, Nguyen, Anthony L,
Kitszel, Przemyslaw, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
Kiszka, Jan
Cc: intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, wq.wang@siemens.com
In-Reply-To: <d058b0fa9ad923514084a44f51c78ae8355c4ebb.camel@siemens.com>
On 24/06/2026 11:05, Florian Bezdeka via Intel-wired-lan wrote:
> On Tue, 2026-06-23 at 09:46 +0000, Kwapulinski, Piotr wrote:
>>> -----Original Message-----
>>> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Ding Meng via Intel-wired-lan
>>> Sent: Monday, June 22, 2026 6:13 AM
>>> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; andrew+netdev@lunn.ch; davem@davemloft.net; edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; Kiszka, Jan <jan.kiszka@siemens.com>; Bezdeka, Florian <florian.bezdeka@siemens.com>
>>> Cc: intel-wired-lan@lists.osuosl.org; linux-kernel@vger.kernel.org; netdev@vger.kernel.org; meng.ding@siemens.com; wq.wang@siemens.com
>>> Subject: [Intel-wired-lan] [PATCH net] igc: Fix RX HW timestamp reporting when NET_RX_BUSY_POLL is disabled
>>>
>>> When CONFIG_NET_RX_BUSY_POLL is deactivated, fetching RX HW timestamps from the NIC no longer works as expected.
>>>
>>> This occurs because disabling CONFIG_NET_RX_BUSY_POLL disables the SKB NAPI mapping in __skb_mark_napi_id(). Consequently, get_timestamp() fails to perform its driver lookup, and the igc driver's struct net_device_ops::ndo_get_tstamp is never invoked.
>>>
>>> Instead, get_timestamp() falls back to use shhwtstamps(skb)->hwtstamp, a field that the driver has not populated.
>>>
>>> Fix this by populating the hwtstamp field with the correct timestamp in the default timer when CONFIG_NET_RX_BUSY_POLL is disabled.
>>>
>>> Fixes: 069b142f5819 ("igc: Add support for PTP .getcyclesx64()")
>>> Co-developed-by: Florian Bezdeka <florian.bezdeka@siemens.com>
>>> Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
>>> Signed-off-by: Ding Meng <meng.ding@siemens.com>
>>> ---
>>> drivers/net/ethernet/intel/igc/igc_main.c | 38 ++++++++++++++++-------
>>> 1 file changed, 26 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
>>> index 8ac16808023..1da8d7aa76d 100644
>>> --- a/drivers/net/ethernet/intel/igc/igc_main.c
>>> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
>>> @@ -1992,7 +1992,26 @@ static struct sk_buff *igc_build_skb(struct igc_ring *rx_ring,
>>> return skb;
>>> }
>>>
>>> -static struct sk_buff *igc_construct_skb(struct igc_ring *rx_ring,
>>> +static void igc_construct_skb_timestamps(struct igc_adapter *adapter,
>>> + struct sk_buff *skb,
>>> + struct igc_xdp_buff *ctx)
>>> +{
>>> + if (!ctx->rx_ts)
>>> + return;
>>> +#ifdef CONFIG_NET_RX_BUSY_POLL
>>> + skb_shinfo(skb)->tx_flags |= SKBTX_HW_TSTAMP_NETDEV;
>>> + skb_hwtstamps(skb)->netdev_data = ctx->rx_ts; #else
>>> + struct igc_inline_rx_tstamps *tstamps;
>> Please move at the top of the function and add:
>
> That would trigger a "unused variable" warning in the
> CONFIG_NET_RX_BUSY_POLL case.
Put it under #ifndef CONFIG_NET_RX_BUSY_POLL. Variable declarations
need to be on top.
Thanks,
Marcin
> Btw: I was really confused that the #else statement moved to the end of
> the previous line. Might someone be using a wrongly configured mail
> client here?
>
> Florian
>
>> Reviewed-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com
>>
>>> +
>>> + tstamps = ctx->rx_ts;
>>> + skb_hwtstamps(skb)->hwtstamp = igc_ptp_rx_pktstamp(adapter,
>>> + tstamps->timer0);
>>> +#endif
>>> +}
>>> +
>
> [snip]
^ permalink raw reply
page: next (older)
- 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