Messages in this thread | | | Date | Thu, 14 Aug 2008 16:28:37 +0300 | From | "Pekka Enberg" <> | Subject | Re: [RFC][PATCH] netconsole: avoid deadlock on printk from driver code |
| |
Hi David,
On Wed, Aug 13, 2008 at 1:37 PM, David Miller <davem@davemloft.net> wrote: > From: Vegard Nossum <vegardno@ifi.uio.no> > Date: Wed, 13 Aug 2008 11:53:24 +0200 > >> [PATCH] netconsole: avoid deadlock on printk from driver code >> >> I encountered a hard-to-debug deadlock when I pulled out the plug of my >> RealTek 8139 which was also running netconsole: The driver wants to print >> a "link down" message. However, this triggers netconsole, which wants to >> print the message using the same device. Here is a backtrace: > > See my other reply, this is absolutely the wrong way to go about > this. > > You only have two sane options: > > 1) Defer the link status printk message into a deferred context, > such as a workqueue, so that you can do it outside of the > lock.
It's not just the link status. We have assert() and debugging printks there under tp->lock as well which can also trigger the deadlock condition.
On Wed, Aug 13, 2008 at 1:37 PM, David Miller <davem@davemloft.net> wrote: > 2) Do your locking differently so that the link status handling > locking does not bisect the locking used for packet transmit > in ->hard_start_xmit(). > > #2 is the reason why most other drivers don't have this silly > bug, they don't hold TX path locks when handling link status > and printing out such messages.
Yeah, that works for the link status case, but not for things like the printks in rtl8139_tx_interrupt()... Hmm.
Pekka
| |