[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1275940248.26597.70.camel@calx>
Date: Mon, 07 Jun 2010 14:50:48 -0500
From: Matt Mackall <mpm@...enic.com>
To: Flavio Leitner <fleitner@...hat.com>
Cc: netdev@...r.kernel.org, David Miller <davem@...emloft.net>,
Cong Wang <amwang@...hat.com>, Jay Vosburgh <fubar@...ibm.com>,
Flavio Leitner <fbl@...close.org>,
Andy Gospodarek <gospo@...hat.com>,
Neil Horman <nhorman@...driver.com>,
Jeff Moyer <jmoyer@...hat.com>,
Stephen Hemminger <shemminger@...ux-foundation.org>,
lkml <linux-kernel@...r.kernel.org>,
bridge@...ts.linux-foundation.org,
bonding-devel@...ts.sourceforge.net
Subject: Re: [PATCH] netconsole: queue console messages to send later
On Mon, 2010-06-07 at 16:24 -0300, Flavio Leitner wrote:
> There are some networking drivers that hold a lock in the
> transmit path. Therefore, if a console message is printed
> after that, netconsole will push it through the transmit path,
> resulting in a deadlock.
This is an ongoing pain we've known about since before introducing the
netpoll code to the tree.
My take has always been that any form of queueing is contrary to the
goal of netpoll: timely delivery of messages even during machine-killing
situations like oopses. There may never be a second chance to deliver
the message as the machine may be locked solid. And there may be no
other way to get the message out of the box in such situations. Adding
queueing is a throwing-the-baby-out-with-the-bathwater fix.
I think Dave agrees with me here, and I believe he's said in the past
that drivers trying to print messages in such contexts should be
considered buggy.
--
Mathematics is the supreme nostalgia of our time.
--
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