lkml.org 
[lkml]   [2016]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCHv4 6/6] printk: remove zap_locks() function
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

\
 
 \ /
  Last update: 2016-12-01 03:18    [W:0.091 / U:0.776 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site