Messages in this thread | | | Subject | Re: [PATCH 1/3] printk: Release console_sem after logbuf_lock | From | Peter Zijlstra <> | Date | Fri, 10 Jun 2011 11:40:44 +0200 |
| |
On Fri, 2011-06-10 at 11:33 +0200, Ingo Molnar wrote: > * Andrew Morton <akpm@linux-foundation.org> wrote: > > > > Some notes: > > > > Stupid thing doesn't explain the magical locking though :( I'm > > 99.9% sure that putting an up() inside a spinlock_irq()ed region > > was deliberate. > > My guess would be it's done so that pending irqs that have queued up > during our current printk-ing activities do not hit us with the > console still locked.
Ah, so we already flushed the buffer, but have console_sem locked, so any interrupt that comes in and prints something will place it in the buffer but find console_sem is taken, so not flush it.
Then when we're back to doing up() the buffer is filled and nobody will flush it.
I guess, we can write it like:
spin_unlock(&logbuf_lock); up(&console_sem); local_irq_restore(flags);
which would keep interrupt disabled over up(), but have the logbuf_lock dropped.
| |