Messages in this thread | | | From | Jeff Moyer <> | Date | Wed, 8 Sep 2004 07:54:57 -0400 | Subject | Re: netpoll trapped question |
| |
==> Regarding Re: netpoll trapped question; Herbert Xu <herbert@gondor.apana.org.au> adds:
herbert> Herbert Xu <herbert@gondor.apana.org.au> wrote: >> Jeff Moyer <jmoyer@redhat.com> wrote: >>> mpm> Yes, true. But we're still in trouble if we have nic irq handler -> mpm> take private lock -> printk -> netconsole -> nic irq handler -> take mpm> private lock. See? >>> Okay, so that one has to be addressed on a per-driver basis. There's >>> no way for us to detect that situation. And how do drivers address >>> this? Simply don't printk inside the lock? I think that's reasonable.
>> Why not queue the message whenever you're in IRQ context, and only print >> when you are not?
This question has been answered before. We don't want to defer the output of say an oops or panic message, since we may never get back to process context.
herbert> Actually how can this happen at all? The IRQ handler should've herbert> disabled local IRQs which prevents the second handler from herbert> occuring.
The netpoll infrastructure calls into the device's netpoll routine. This will, in turn, call the interrupt routine for the device.
-Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |