lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 11 Feb 2020 22:27:54 -0500 From: Steven Rostedt <rostedt@...dmis.org> To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> Cc: Petr Mladek <pmladek@...e.com>, Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org, Sergey Senozhatsky <sergey.senozhatsky@...il.com>, Andrew Morton <akpm@...ux-foundation.org>, Dmitry Monakhov <dmtrmonakhov@...dex-team.ru>, Konstantin Khlebnikov <khlebnikov@...dex-team.ru> Subject: Re: [PATCH] kernel/watchdog: flush all printk nmi buffers when hardlockup detected On Wed, 12 Feb 2020 12:04:03 +0900 Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> wrote: > Oh, yes, ftrace printks a lot. But I sort of forgot why don't we do > the same for "regular" NMIs. So NMIs use per-cpu buffers, expect for > NMIs which involve ftrace dump. I'm missing something here. Well, ftrace_dump() is called from NMI context when the system is about to crash (ftrace_dump_on_oops). And at that moment, we care more about the trace than other output (it's most like to contain the information that caused the bug). But for things like sysrq-l, that does a printk in NMI context for normal operations, we don't want strange races to occur and affect other printk operations. Having them in buffers controls the output a bit better. But with the new printk ring buffer work, perhaps that's no longer necessary. -- Steve
Powered by blists - more mailing lists