[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080814.151331.114224935.davem@davemloft.net>
Date: Thu, 14 Aug 2008 15:13:31 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: penberg@...helsinki.fi
Cc: vegard.nossum@...il.com, vegardno@....uio.no,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
jgarzik@...ox.com, adobriyan@...il.com
Subject: Re: [RFC][PATCH] netconsole: avoid deadlock on printk from driver
code
From: "Pekka Enberg" <penberg@...helsinki.fi>
Date: Thu, 14 Aug 2008 16:28:37 +0300
> On Wed, Aug 13, 2008 at 1:37 PM, David Miller <davem@...emloft.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.
Note that netconsole specifically does trylock on the netdev
xmit lock specifically to handle this case.
If you could command the TX path solely under this generic lock
already provided by the generic networking, you could avoid this
deadlock as well.
This is yet another reason many other drivers don't get hit by
this problem. The solution is built into netpoll but it only
works if you use the provided generic locking mechanisms to
mutex the driver's TX path.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists