lkml.org 
[lkml]   [2016]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCHv5 7/7] printk: remove zap_locks() function
On Thu 2016-12-01 22:55:46, Sergey Senozhatsky wrote:
> We use printk-safe now which makes printk-recursion detection code
> in vprintk_emit() unreachable. The tricky thing here is that, apart
> from detecting and reporting printk recursions, that code also used
> to zap_locks() in case of panic() from the same CPU. However,
> zap_locks() does not 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'.
>
> 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. The only
> reaming difference is that we don't re-init the console semaphore in
> printk_safe_flush_on_panic(), but this is not necessary because we
> don't call console drivers from printk_safe_flush_on_panic() due to
> the fact that we are using a deferred printk() version (as was
> suggested by Petr Mladek).
>
> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>

I like this patch. The code is unused after protecting the section
by printk_safe_enter()/exit(). And also the panic mode is handled
by the commits mentioned above.

Reviewed-by: Petr Mladek <pmladek@suse.com>

Best Regards,
Petr

\
 
 \ /
  Last update: 2016-12-12 17:38    [W:0.159 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site