Re: [PATCH] net/iavf: fix reset race condition

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

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 <ciara.loftus@intel.com>
> ---

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 <anatoly.burakov@intel.com>

-- 
Thanks,
Anatoly