On Thu 2016-12-01 21:50:45, Sergey Senozhatsky wrote:
> On (11/25/16 16:01), Petr Mladek wrote:
> [..]
> > > apart from detecting and reporting printk recursions, that code also
> > > used to zap_lockc() in case of panic. However, zap_locks() does not
> >                       ^
> > 
> > s/zap_lockc/zap_locks/
> > 
> > > look to be needed anymore:
> > > 
> > > 1) Since commit 08d78658f393 ("panic: release stale console lock to
> > >    always get the logbuf printed out") panic flushing of `logbuf' to
> > >    console ignores the state of `console_sem' by doing
> > >           panic()
> > >           console_trylock();
> > >           console_unlock();
> > > 
> > > 2) Since commit cf9b1106c81c ("printk/nmi: flush NMI messages on the
> > >    system panic") panic attempts to zap the `logbuf_lock' spin_lock to
> > >    successfully flush nmi messages to `logbuf'.
> > 
> > Note that the same code is newly used to flush also the printk_safe
> > per-CPU buffers. It means that logbuf_lock is zapped also when
> > flushing these new buffers.
> 
> 
> not quite. there are several checks that would prevent multiple logbuf_lock
> re-inits:

Ah, I did not meant that the lock was zapped twice. I wanted to say
that we added a new path and that it was handled as well :-)

Best Regards,
Petr

Reply via email to