Messages in this thread | | | Date | Mon, 12 Dec 2016 17:37:27 +0100 | From | Petr Mladek <> | Subject | Re: [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
| |