Re: [PATCH net 1/4] iavf: return EBUSY if reset in progress or not ready during MAC change

[Jose Ignacio Tornos Martinez <jtornosm@redhat.com>]

Hello Jakub,

> You're not fully fixing the issue, and sprinkle in EBUSY returns to user
> space instead of waiting. I'm afraid that below the bar.

The -EBUSY here is not replacing a useful wait — during reset,
the admin queue is down and the wait would block for 2.5s on a
non-functional queue and could still fail anyway.

This patch is preparatory for patch 3/4 which replaces the
wait_event with a synchronous virtchnl send + poll, eliminating
the wait under netdev_lock entirely.

The early -EBUSY here is needed because the synchronous path in
patch 3/4 must not attempt to send a virtchnl message when the VF
is resetting or not yet initialized — the admin queue is down or
in an undefined state, the message cannot reach the PF, and the
poll would hold netdev_lock for up to 2.5s on a non-functional
queue, blocking iavf_reset_task() which also needs netdev_lock
to proceed with recovery.

In short, it prevents the synchronous poll from blocking reset
recovery by holding netdev_lock on a dead queue, without
disrupting the existing driver reset recovery flow.

I think failing fast with -EBUSY during reset/initialization is
the correct behavior: it avoids delaying reset recovery and the
caller can retry once the reset completes (milliseconds to
seconds). The full fix is in patch 3/4 which carries the Fixes:
tag and cc: stable.

Without this guard, the synchronous path in patch 3/4 would wait
for 2.5s during reset on a non-functional queue and still could
fail with -EAGAIN, while holding netdev_lock and delaying
recovery. The -EBUSY avoids that pointless wait.

Thanks

Best regards
José Ignacio