Re: LLTX and netif_stop_queue

[Roland Dreier <roland@xxxxxxxxxxx>]

    Roland> This seems a little risky.  I can't point to a specific
    Roland> deadlock but it doesn't seem right on general principles
    Roland> to unlock in a different order than you nested the locks
    Roland> when acquiring them -- if I understand correctly, you're
    Roland> suggesting lock(queue_lock), lock(tx_lock),
    Roland> unlock(queue_lock), unlock(tx_lock).

    jamal> There is no deadlock. Thats exactly how things work. Try
    jamal> the patches i posted.

Thinking about it more, I guess it's OK.  I was just think about the
basic general rule that locks need to be acquired/released in LIFO
order to avoid deadlock (eg lock(A), lock(B), unlock(B), unlock(A)).

However in this case unlocking queue_lock after acquiring the driver's
tx_lock seems to be OK because the driver does a trylock on tx_lock in
the xmit path, so it can't deadlock.  At worst the trylock will just
fail to get the lock.

Thanks,
  Roland