Re: [PATCH 2/2] net/mana: fix Rx interrupt enable failing on lock contention

[Orgad Shaneh <orgads@gmail.com>]

Hi Wei,

Wei Hu <weh@microsoft.com> 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