From: Matt Mackall <[EMAIL PROTECTED]>
Date: Tue, 6 Sep 2005 15:50:25 -0700
> > So we try to spit out netconsole messages in hw IRQ context and stuff
> > like that, as you stated. The tg3 driver is susceptible to the
> > problem you mention, as is bnx2, because they use purely software
> > interrupt spinlocking, and thus their timers will deadlock if any hw
> > IRQ context netpoll operations occur.
>
> I'm not aware of the tg3 problem, please describe it in more detail.
Any driver which takes locks only with BH disabled are going
to die in a deadlock with the current netpoll.
If a timer handler in the driver takes the driver spinlock
with only BH disabling, then a netpoll request comes in
and this lock is taken again in either the ->poll() or
->hard_start_xmit() routine we'll die.
This is the case in the bnx2 driver, example deadlock is:
bnx2_timer()
{
...
spin_lock(&bp->phy_lock);
...
hw interrupt
netpoll
...
bnx2_poll()
{
...
spin_lock(&bp->phy_lock);
See?
In the current tg3, the driver very much assumes that the only thread
of control into the driver code in HW interrupt context is the
tg3_interrupt() handler. This allows us to do no locking at all with
hw IRQ context, we just use synchronize_irq() when shutting the chip
down to reach a quiescent state. Therefore all spinlocks can be
taken with BH disabling only. BNX2, above, achieves this capability
in a slightly different way.
So you cannot call into these drivers with HW interrupts disabled or
even worse from HW interrupt context. These drivers use locking
strategies which are perfectly legal and work until you add netpoll.
-
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
