[Top] [All Lists]

Re: patch for common networking error messages

To: Andi Kleen <ak@xxxxxxx>
Subject: Re: patch for common networking error messages
From: Andrew Morton <akpm@xxxxxxxxx>
Date: Tue, 17 Jun 2003 00:20:27 -0700
Cc: davem@xxxxxxxxxx, ak@xxxxxxx, janiceg@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, stekloff@xxxxxxxxxx, girouard@xxxxxxxxxx, lkessler@xxxxxxxxxx, kenistonj@xxxxxxxxxx, jgarzik@xxxxxxxxx
In-reply-to: <20030617070957.GB2752@xxxxxxxxxxxxx>
References: <3EEE28DE.6040808@xxxxxxxxxx> <20030616.133841.35533284.davem@xxxxxxxxxx> <20030616205342.GH30400@xxxxxxxxxxxxx> <20030616.135124.71580008.davem@xxxxxxxxxx> <20030616152707.58da808c.akpm@xxxxxxxxx> <20030617070957.GB2752@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
Andi Kleen <ak@xxxxxxx> wrote:
> > Actually it already does, to cover the case where an interrupt handler calls
> > printk while process-context code is performing a printk.
> I don't think it'll work. Both printk and release_console_sem take the 
> logbuf_lock,
> which will deadlock if the same CPU already holds it.

Look more closely.

logbuf_lock is only held to protect the logbuf contents and its indices. 
And to pin down the current console_sem holder to reliably ensure that
he'll print the text which the nested printer just placed in the buffer.

We do not call the console drivers while holding logbuf_lock.  console_sem
is held across the console driver call.

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