Messages in this thread | | | Date | Mon, 15 Jul 2019 16:54:52 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH] kernel/printk: prevent deadlock at calling kmsg_dump from NMI context |
| |
On (07/15/19 10:38), Konstantin Khlebnikov wrote: > > > Indeed, panic is especially handled and looks fine. > > > > > > Sanity check in my patch could be relaxed: > > > > > > if (WARN_ON_ONCE(reason != KMSG_DUMP_PANIC && in_nmi())) > > > return; > > > > How critical kmsg_dump() is? We deadlock only if NMI->kmsg_dump() > > happens on the CPU which already holds the logbuf_lock; in any > > other case logbuf_lock is owned by another CPU which is expected > > to unlock it eventually. So it doesn't look like disabling all > > NMI->kmsg_dump() is the only way to fix it. > > > > When we lock logbuf_lock we increment per-CPU printk_context > > (PRINTK_SAFE_CONTEXT_MASK bits); when we unlock logbuf_lock > > we decrement printk_context. Thus we always can tell if the > > logbuf_lock was locked on the very same CPU - this_cpu printk_context > > has PRINTK_SAFE_CONTEXT_MASK bits sets - and we are about to deadlock > > in a nested context (NMI), or the lock was locked on another CPU and > > it's "safe" to spin on logbuf_lock and wait for logbuf_lock to become > > available. > > I see no users who dumps dmesg from NMI context except panic. > This shouldn't happen. But might happen is something goes very wrong.
I see. OK, if NMI->kmsg_dump() never happens (except for panic) then we are fine, I guess.
-ss
| |