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:42:46 +0200 |
| |
On Fri, 2011-06-10 at 11:40 +0200, Peter Zijlstra wrote: > 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.
Ah, not so, another cpu could start printing stuff.
So what we need is another test of log_start - log_end after up().
| |