On 9/24/2026 10:41 AM, Ciara Loftus wrote:
iavf_handle_hw_reset() can be called concurrently from the iavf-event
thread handling RTE_ETH_EVENT_INTR_RESET and from any thread calling
rte_pmd_iavf_reinit() (VF-initiated reset), with no synchronisation
between the two. Make in_reset_recovery atomic and use it as a guard
so only one reset runs at a time.
Fixes: 28a1a72eac26 ("net/iavf: add VF initiated reset")
Signed-off-by: Ciara Loftus <[email protected]>
---
There's an AI review comment about a potential stale in_reset_recovery
state when init/uninit fails in certain cases. I've taken the liberty to
check this against the code, and it seems to be a false positive.
My own AI review flagged the following:
```
iavf_ethdev.c:3747: after observing false, this function reads
start_pending, dev_started, link_up that the reset thread wrote before
its release-store. A relaxed load does not formally synchronize with
that release, so on weakly-ordered CPUs those reads could be stale. Use
rte_memory_order_acquire here.
iavf_ethdev.c:3547-3548: vf->pf_reset_in_progress = false is written
after the release-store, so it is not covered by it. A concurrent
dev_close() on another thread that sees the flag cleared could still see
pf_reset_in_progress == true and skip iavf_vf_reset()/flow flush. Swap
the two lines.
```
However, if we're running two dev_close() calls concurrently we've got
way bigger problems so I don't think the second finding is meaningful.
The first one may be a "correctness" issue but not blocking either.
So, LGTM (with or without the above suggested fixed)
Acked-by: Anatoly Burakov <[email protected]>
--
Thanks,
Anatoly
