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


Groups > linux.kernel > #1530328

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

From Petr Mladek <pmladek@suse.com>
Newsgroups linux.kernel
Subject Re: [RFC][PATCHv4 6/6] printk: remove zap_locks() function
Date 2016-11-25 16:20 +0100
Message-ID <sHqsa-2er-21@gated-at.bofh.it> (permalink)
References <swVfX-3Pm-11@gated-at.bofh.it> <swVfY-3Pm-23@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.


> 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>

Best Regards,
Petr

Back to linux.kernel | Previous | NextNext 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