Krishna Kumar2 wrote:
What about a race between trying to reacquire queue_lock and another
failed transmit?
That is not possible too. I hold the QDISC_RUNNING bit in dev->state and
am the only sender for this device, so there is no other failed transmit.
Also, on failure of dev_hard_start_xmit, qdisc_restart will spin for the
queue lock (which could be held quickly by enqueuer's), and q->requeue()
skbs to the head of the list.
I have to claim incomplete familiarity for the code. But still, if
you're out there running with no locks for a period, there's no
assumption you can make. The "lock could be held quickly" assertion is a
fallacy.
Thanks,
- KK
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
