Re: + panic-avoid-the-extra-noise-dmesg.patch added to -mm tree

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

On (12/05/18 09:53), Feng Tang wrote:
> > I think that we could simply clear panic_blinking from
> > __handle_sysrq(). The user will still be able to capture the screen
> > before touching the keyboard. But it will keep the things simple.
> > 
> > I hope that we did not miss anything else. Anyway, the approach with
> > making printk a nop still looks like the best maintainable solution
> > to me.
>  
> I will setup a platform which can handle sysrq request and try your
> suggestion. thanks,

I don't entirely understand this patch series, sorry. So you want to
keep local IRQs disabled to, supposedly, have less printk-s between
dump_stack() from panic CPU and "end Kernel panic" marker; yet at the
same time you add *significantly* more printk-s between dump_stack()
from panic CPU and "end Kernel panic" marker.

panic_print_sys_info() can be very verbose, and it happens much later
than dump_stack() from panic CPU. So you are guaranteed to have same
problems you are trying to avoid: "the original context gets
lost on screen" and "confused people post bad bug reports".

Am I missing something?

Dunno. Just a bunch of ideas (raw ideas).
Is something like below going to work for you instead?

---

@@ -327,6 +327,9 @@ void panic(const char *fmt, ...)
 #endif
 	pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf);
 	local_irq_enable();
+
+	dump_stack();
+
 	for (i = 0; ; i += PANIC_TIMER_STEP) {
 		touch_softlockup_watchdog();
 		if (i >= i_next) {

---

Or... *Maybe* you can even do a ratelimited dump_stack() from that
PANIC_TIMER_STEP loop. Say, one dump_stack() every 10 minutes. The
WARN_ON noise should stop at some point.

	-ss