Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1533749

Re: [RFC][PATCHv4 6/6] printk: remove zap_locks() function

Show all headers | View raw

On (11/25/16 16:01), Petr Mladek wrote:
> On Fri 2016-10-28 00:49:33, Sergey Senozhatsky wrote:
> > We use printk-safe now which makes printk-recursion detection code
> > in vprintk_emit() is unreachable. The tricky thing here is that,
>      		    ^^ superfluous "is"
> 
> > 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.

yes, and I'm a bit skeptical about the whole re-init logbuf_lock,
because this lock is just one of possibly many looks that can be
'locked'. the messages are already in per-CPU buffers, so they
will present in a core dump file.

but it can be done separately, not in this series.

> > Basically, it seems that we either already do what zap_locks() used to
> > do but in other places or we ignore the state of the lock. May be we
> > still would want to do sema_init() in printk_safe_flush_on_panic(),
> > just in case.
> 
> Very good question! I would actually suggest to use printk_deferred()
> in printk_safe_flush_on_panic() in any context. It will solve the
> problems discussed for the 4th patch of this patchset. And it will
> solve also this problem. In case of panic, we should first try to
> get all messages into the logbuffer so that they are visible in
> the crash dump. We try to push them to the console by
> console_flush_on_panic() later because it is more risky.
>
> > Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> 
> If we avoid calling console in printk_safe_flush_on_panic(),
> feel free to use:
> 
> Reviewed-by: Petr Mladek <pmladek@suse.com>

ok. thanks.

	-ss

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [RFC][PATCHv4 6/6] printk: remove zap_locks() function Petr Mladek <pmladek@suse.com> - 2016-11-25 16:20 +0100
  Re: [RFC][PATCHv4 6/6] printk: remove zap_locks() function Peter Zijlstra <peterz@infradead.org> - 2016-11-25 16:20 +0100
    Re: [RFC][PATCHv4 6/6] printk: remove zap_locks() function Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-12-01 03:40 +0100
      Re: [RFC][PATCHv4 6/6] printk: remove zap_locks() function Peter Zijlstra <peterz@infradead.org> - 2016-12-01 06:50 +0100
        Re: [RFC][PATCHv4 6/6] printk: remove zap_locks() function Petr Mladek <pmladek@suse.com> - 2016-12-01 14:40 +0100
          Re: [RFC][PATCHv4 6/6] printk: remove zap_locks() function Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-12-02 02:20 +0100
  Re: [RFC][PATCHv4 6/6] printk: remove zap_locks() function Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-12-01 03:20 +0100
  Re: [RFC][PATCHv4 6/6] printk: remove zap_locks() function Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-12-01 14:00 +0100
    Re: [RFC][PATCHv4 6/6] printk: remove zap_locks() function Petr Mladek <pmladek@suse.com> - 2016-12-01 14:20 +0100

csiph-web