| 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@wotan.suse.de> |
| References: | <3EEE28DE.6040808@us.ibm.com> <20030616.133841.35533284.davem@redhat.com> <20030616205342.GH30400@wotan.suse.de> <20030616.135124.71580008.davem@redhat.com> <20030616152707.58da808c.akpm@digeo.com> <20030617070957.GB2752@wotan.suse.de> |
| 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. |
| Previous by Date: | Re: Route cache performance tests, David S. Miller |
|---|---|
| Next by Date: | Re: Route cache performance under stress, Robert Olsson |
| Previous by Thread: | Re: patch for common networking error messages, Andi Kleen |
| Next by Thread: | Re: patch for common networking error messages, Janice M Girouard |
| Indexes: | [Date] [Thread] [Top] [All Lists] |