patch 'net/iavf: fix interrupt callback race on close' has been queued to stable release 24.11.9
luca.boccassi at gmail.com
luca.boccassi at gmail.com
Thu Nov 5 17:42:14 CET 2026
Hi,
FYI, your patch has been queued to stable release 24.11.9
Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 11/07/26. So please
shout if anyone has objections.
Also note that after the patch there's a diff of the upstream commit vs the
patch applied to the branch. This will indicate if there was any rebasing
needed to apply to the stable branch. If there were code changes for rebasing
(ie: not only metadata diffs), please double check that the rebase was
correctly done.
Queued patches are on a temporary branch at:
https://github.com/bluca/dpdk-stable
This queued commit can be viewed at:
https://github.com/bluca/dpdk-stable/commit/c2a50ec45ec7bd2bdfe198551a98752534771472
Thanks.
Luca Boccassi
---
>From c2a50ec45ec7bd2bdfe198551a98752534771472 Mon Sep 17 00:00:00 2001
From: Marek Kasiewicz <marek.kasiewicz at intel.com>
Date: Wed, 14 Oct 2026 12:24:27 +0000
Subject: [PATCH] net/iavf: fix interrupt callback race on close
[ upstream commit 789a0ad379a427c76d3e98b9fb76c23c4ef33fcc ]
In iavf_dev_close(), rte_intr_callback_unregister() can return -EAGAIN
while the interrupt thread is executing a callback for the same source.
The return value is ignored, leaving the callback registered.
Close hits that window. It sends virtchnl commands (RSS, promiscuous
mode, flows), and iavf_dev_interrupt_handler() handles each response.
The handler clears the pending command before it returns, so the
thread waiting in iavf_wait_for_msg() can go on to the unregister
while the interrupt thread is still inside the callback. This is
likely when the two threads share a CPU.
Two failures follow:
- The interrupt thread resumes the callback after
rte_eth_dev_release_port() has set dev->data to NULL, and
iavf_handle_virtchnl_msg() dereferences it: segmentation fault.
- The callback returns, but its source stays registered after the
port is closed. At rte_eal_cleanup(),
pci_vfio_unmap_resource_primary() closes the interrupt eventfd, and
the next rebuild of the epoll set aborts the process:
EAL: PANIC in eal_intr_thread_main():
Error adding fd 49 epoll_ctl, Bad file descriptor
Use rte_intr_callback_unregister_sync(), as ice_dev_close() does. The
iavf_dev_init() error path has the same pattern; fix it too.
The sync variant waits for a running callback to return. It would
spin forever only if called from iavf_dev_interrupt_handler() itself,
and that handler never closes or re-initializes the port: it hands PF
events and resets to the iavf-event thread with iavf_dev_event_post().
A close from any other interrupt thread callback, such as an alarm,
returns at once, because the iavf source is not active then.
Fixes: 22b123a36d07 ("net/avf: initialize PMD")
Fixes: e35a5737a746 ("net/iavf: unregister interrupt handler before FD close")
Signed-off-by: Marek Kasiewicz <marek.kasiewicz at intel.com>
Signed-off-by: Dawid Wesierski <dawid.wesierski at intel.com>
Acked-by: Bruce Richardson <bruce.richardson at intel.com>
---
drivers/net/iavf/iavf_ethdev.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index bd3c394aa08..8ec31b78789 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -2945,8 +2945,8 @@ flow_init_err:
rte_intr_disable(pci_dev->intr_handle);
/* unregister callback func from eal lib */
- rte_intr_callback_unregister(pci_dev->intr_handle,
- iavf_dev_interrupt_handler, eth_dev);
+ rte_intr_callback_unregister_sync(pci_dev->intr_handle,
+ iavf_dev_interrupt_handler, eth_dev);
} else {
rte_eal_alarm_cancel(iavf_dev_alarm_handler, eth_dev);
}
@@ -3036,8 +3036,8 @@ iavf_dev_close(struct rte_eth_dev *dev)
rte_intr_disable(intr_handle);
/* unregister callback func from eal lib */
- rte_intr_callback_unregister(intr_handle,
- iavf_dev_interrupt_handler, dev);
+ rte_intr_callback_unregister_sync(intr_handle,
+ iavf_dev_interrupt_handler, dev);
} else {
rte_eal_alarm_cancel(iavf_dev_alarm_handler, dev);
}
--
2.47.3
---
Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- - 2026-11-05 16:42:46.801666634 +0000
+++ 0047-net-iavf-fix-interrupt-callback-race-on-close.patch 2026-11-05 16:42:44.953061742 +0000
@@ -1 +1 @@
-From 789a0ad379a427c76d3e98b9fb76c23c4ef33fcc Mon Sep 17 00:00:00 2001
+From c2a50ec45ec7bd2bdfe198551a98752534771472 Mon Sep 17 00:00:00 2001
@@ -5,0 +6,2 @@
+[ upstream commit 789a0ad379a427c76d3e98b9fb76c23c4ef33fcc ]
+
@@ -40 +41,0 @@
-Cc: stable at dpdk.org
@@ -46 +47 @@
- drivers/net/intel/iavf/iavf_ethdev.c | 8 ++++----
+ drivers/net/iavf/iavf_ethdev.c | 8 ++++----
@@ -49,5 +50,5 @@
-diff --git a/drivers/net/intel/iavf/iavf_ethdev.c b/drivers/net/intel/iavf/iavf_ethdev.c
-index 9e0e13d499..a2be58f1a8 100644
---- a/drivers/net/intel/iavf/iavf_ethdev.c
-+++ b/drivers/net/intel/iavf/iavf_ethdev.c
-@@ -3166,8 +3166,8 @@ flow_init_err:
+diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
+index bd3c394aa08..8ec31b78789 100644
+--- a/drivers/net/iavf/iavf_ethdev.c
++++ b/drivers/net/iavf/iavf_ethdev.c
+@@ -2945,8 +2945,8 @@ flow_init_err:
@@ -60,0 +62,2 @@
+ } else {
+ rte_eal_alarm_cancel(iavf_dev_alarm_handler, eth_dev);
@@ -62,3 +65 @@
- iavf_phc_sync_alarm_stop(eth_dev);
- rte_eal_alarm_cancel(iavf_dev_alarm_handler, eth_dev);
-@@ -3263,8 +3263,8 @@ iavf_dev_close(struct rte_eth_dev *dev)
+@@ -3036,8 +3036,8 @@ iavf_dev_close(struct rte_eth_dev *dev)
@@ -71,0 +73,2 @@
+ } else {
+ rte_eal_alarm_cancel(iavf_dev_alarm_handler, dev);
@@ -73,2 +75,0 @@
- iavf_phc_sync_alarm_stop(dev);
- rte_eal_alarm_cancel(iavf_dev_alarm_handler, dev);
More information about the stable
mailing list