[Top] [All Lists]

Re: [PATCH] Prevent netpoll hanging when link is down

To: Matt Mackall <mpm@xxxxxxxxxxx>
Subject: Re: [PATCH] Prevent netpoll hanging when link is down
From: Andi Kleen <ak@xxxxxxx>
Date: Mon, 11 Oct 2004 19:41:12 +0200
Cc: Andi Kleen <ak@xxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxx>, colin@xxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20041011165851.GN31237@xxxxxxxxx>
References: <20041008090610.70d7e183@pirandello> <20041008220001.GE31237@xxxxxxxxx> <20041008151839.01823e0c.akpm@xxxxxxxx> <20041010205928.6e54df7e.davem@xxxxxxxxxxxxx> <20041011154000.GB26350@xxxxxxxxxxxxx> <20041011162224.GL31237@xxxxxxxxx> <20041011163226.GG26350@xxxxxxxxxxxxx> <20041011163601.GM31237@xxxxxxxxx> <20041011164315.GH26350@xxxxxxxxxxxxx> <20041011165851.GN31237@xxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Mon, Oct 11, 2004 at 11:58:52AM -0500, Matt Mackall wrote:
> On Mon, Oct 11, 2004 at 06:43:15PM +0200, Andi Kleen wrote:
> > > It's not recursion on printk that's a problem, it's recursion on
> > > ->poll() and attempting to take whatever internal driver locks.
> > 
> > There is no recursion on poll because printk will never call into
> > the low level console driver when the console sem is already taken.
> Ergh, you deleted the context. Again, imagine we're originally in
> ->poll() for _a non-netpoll-related reason_. In other words, the
> console sem is not taken, because we're just doing routine network
> I/O. While in poll(), we take a private driver lock. Then for whatever
> reason, we printk -> netconsole -> netpoll -> poll() again where we
> attempt to retake the private driver lock.

You're right, in that case you could get a deadlock. 


<Prev in Thread] Current Thread [Next in Thread>