On Tue, 2007-07-24 at 18:47 -0700, David Miller wrote:
> One thing that's peculiar is that when netif_rx_schedule_prep()
> fails, we don't disable interrupts but we also don't clear the
> condition that is causing the interrupt to occur.
I think we're ok, but this stuff is tricky.
In the driver in -rc1, I think it will only fail if racing with the
netif_rx_reschedule, which will do the right thing.
In your version, there is only one place where prep can fail (ie.
interrupts are enabled, but netif_rx_complete() hasn't been called):
when ibmveth_poll saw pending buffers and disabled the irq (which has
already been delivered and is spinning on the poll_lock)
In this case, we're ok because the irqs really are disabled now: the
running handler is a relic.
> Perhaps the lock is avoidable somehow, who knows :)
Maybe by adding YA state bit? Hold on, this might get ugly...
Say netif_rx_schedule_prep() sets the MORE_TODO bit (atomically instead
of setting __LINK_STATE_RX_SCHED) if it's going to fail, and
netif_rx_complete() returns 0 if it was set, or 1 if it's OK. Now
callers do:
reenable_interrupts();
if (rx_pending() || !netif_rx_complete(netdev, napi))
disable_interrupts();
I'm going to go absorb some more caffeine before you reply 8)
Rusty.
-
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
