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@xxxxxxxxxxxxx> wrote:
From: Vegard Nossum <vegardno@xxxxxxxxxx>
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@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/