Hi Wei,
Wei Hu <[email protected]> wrote:
> App threads could get stuck as long as 15 seconds waiting for the lock when
> the device is in reset. Is it better to add following?
The 15 s recovery wait in mana_reset_thread() runs with reset_ops_lock
released and dev_state at RESET_EXIT, so a caller in that window takes
the lock, sees the state and returns -EBUSY at once. The lock is held
during teardown (dev_stop, the RESET_ENTER request to secondaries with
its 5 s IPC timeout, dev_close) and during re-probe, and a caller that
arrives then waits for that step.
Your early check fixes that: both steps run with dev_state already
non-ACTIVE, so the caller returns -EBUSY without touching the lock.
One window stays open. A caller can pass the check just before
mana_intr_handler() takes the lock, then block through
mana_reset_enter() and, if the reset thread wins the lock next,
through the whole teardown. Checking the state while waiting closes
that too, and it is no bigger:
static int
mana_reset_lock(struct mana_priv *priv)
{
while (pthread_mutex_trylock(&priv->reset_ops_lock)) {
if (rte_atomic_load_explicit(&priv->dev_state,
rte_memory_order_relaxed) != MANA_DEV_ACTIVE)
return -EBUSY;
rte_pause();
}
if (rte_atomic_load_explicit(&priv->dev_state,
rte_memory_order_acquire) != MANA_DEV_ACTIVE) {
pthread_mutex_unlock(&priv->reset_ops_lock);
return -EBUSY;
}
return 0;
}
Outside a reset the lock is only held by another queue's doorbell
write or event read, so the spin is short. A caller then never waits
on a reset step at all.
I'll send v2 with this, without Cc: stable, unless you prefer your
version.
Thanks,
Orgad
