On Fri, Dec 05, 2003 at 04:59:00PM -0800, David S. Miller wrote:
This is the classic case of doing disabling/enabling of software
interrupts with hardware interrupts disabled, which is a bug.
In this case pcnet32_set_multicast_list() is disabling hardware
interrupts, and the packet freeing of pcnet32_purge_tx_ring()
is what leads to the software interrupt disable/enable.
I think the root cause of this problem is that pcnet32_set_multicast_list()
dumps the entire TX ring on the floor (as a side effect of calling
pcnet32_restart()). I don't think dev->set_multicast_list() is supposed to
do that.
However, I'm inclined to believe that we should change dev_kfree_skb_any()
to fix this class of problems, by making it check for hardware interrupts
being disabled as well as being in an interrupt.
I've been wondering about this too with the recent netpoll patches. Many
(including pcnet32) implement the poll controller simply as
disable_irq (dev->irq);
driver_interrupt_handler (dev->irq, dev, NULL);
enable_irq (dev->irq);
If the interrupt handler calls dev_kfree_skb_any(), could you then run into
this kind of problem? Or is it just if you call spin_lock_irq*() that you
have a problem?
--
Regards,
Rask Ingemann Lambertsen
On Tue, 9 Dec 2003 15:15:02 +0100
Rask Ingemann Lambertsen [off-list ref] wrote:
On Fri, Dec 05, 2003 at 04:59:00PM -0800, David S. Miller wrote:
quoted
This is the classic case of doing disabling/enabling of software
interrupts with hardware interrupts disabled, which is a bug.
In this case pcnet32_set_multicast_list() is disabling hardware
interrupts, and the packet freeing of pcnet32_purge_tx_ring()
is what leads to the software interrupt disable/enable.
I think the root cause of this problem is that pcnet32_set_multicast_list()
dumps the entire TX ring on the floor (as a side effect of calling
pcnet32_restart()). I don't think dev->set_multicast_list() is supposed to
do that.
The task of dev->set_multicast_list() is to do whatever is necessary
to update the multicast filter.
If the pcnet32 hardware for some odd reason requires that you flush
the TX list, it is appropriate.
I've been wondering about this too with the recent netpoll patches. Many
(including pcnet32) implement the poll controller simply as
disable_irq (dev->irq);
driver_interrupt_handler (dev->irq, dev, NULL);
enable_irq (dev->irq);
If the interrupt handler calls dev_kfree_skb_any(), could you then run into
this kind of problem? Or is it just if you call spin_lock_irq*() that you
have a problem?
No, it would not be a problem because the thing that dev_kfree_skb_any()
_does_ test right now ('in_irq()') would trigger.
Sorry, forgot to mention this in the previous email.
The way to fix this properly in the pcnet32 driver itself would
be to pass a stack local "struct sk_buff_head" list down into
these deep routines while we have the locks held.
Instead of freeing the TX skbs, we add them all to this list.
At the top level, the code drops the spinlock and enables cpu irqs,
then it frees up any SKBs that were put on that list.