Messages in this thread | | | Date | Thu, 1 Dec 2016 11:18:04 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [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
| |