From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 11 Dec 2018 17:00:43 +0900 From: Sergey Senozhatsky To: Feng Tang Cc: Sergey Senozhatsky , Peter Zijlstra , Petr Mladek , akpm@linux-foundation.org, bp@suse.de, keescook@chromium.org, mm-commits@vger.kernel.org, sergey.senozhatsky@gmail.com, stable@vger.kernel.org, tglx@linutronix.de, Steven Rostedt , Sasha Levin , Andi Kleen , linux-kernel@vger.kernel.org Subject: Re: + panic-avoid-the-extra-noise-dmesg.patch added to -mm tree Message-ID: <20181211080043.GA521@jagdpanzerIV> References: <20181204154936.wbgcovzpc54n6dvs@shbuild888> <20181205022654.GA503@jagdpanzerIV> <20181205024713.nqyt6qiamokq7qtl@shbuild888> <20181205025728.GC503@jagdpanzerIV> <20181205052912.GA423@jagdpanzerIV> <20181205080044.GA11190@jagdpanzerIV> <20181205154620.4dqtledc2duhrp2c@shbuild888> <20181206035825.jz2bfh3errj23rjq@shbuild888> <20181207095004.GB3729@jagdpanzerIV> <20181210094554.z5n7dmkrnlcpygg4@shbuild888> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181210094554.z5n7dmkrnlcpygg4@shbuild888> List-ID: Hi, On (12/10/18 17:45), Feng Tang wrote: > Yes, this is very valid concern. And after Petr and you raised it, I did > some experiments with 3 x86 platforms at my hand, one Apollolake IOT device > with serial console, one IvyBridge laptop and one Kabylake NUC, the magic key > all works well before panic, and fails after panic. But I did remember the > PageUp/PageDown key worked on some laptop years ago. And you actually raised a > good question: what do we expect for the post-panic kernel? Yeah. It used to be case that people expected some things to work after panic. > For the v4 patch, my thought is, for experienced developers to make > sysrq/panic_blink work, it's easy to add "panic_keep_irq_on" to kernel cmdline, > or runtime change it by > "echo Y > /sys/module/kernel/parameters/panic_keep_irq_on" > while for normal user, they can by default see the clean panic call stack > either on a screen or a serial console. Before we move on, just a quick question, since I wasn't Cc-ed to v1 and v2 of this patch - did you have a chance to ask x86 people if they can help in any way? Asking to make sure that we are not fixing a _maybe_ x86-specific problem in arch-independent/common code. /* offtopic */ LOL, wish this was a "dumb-and-ugly-solutions" contest; I'm pretty sure I'd take the first prize with this one: --- diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c index 04adc8d60aed..40f643bb7fdc 100644 --- a/arch/x86/kernel/smp.c +++ b/arch/x86/kernel/smp.c @@ -181,6 +181,16 @@ asmlinkage __visible void smp_reboot_interrupt(void) irq_exit(); } +static void native_smp_suppress_reschedule(int cpu) +{ +} + +static void native_smp_to_up(void) +{ + WARN_ON_ONCE(num_online_cpus() > 1); + smp_ops.smp_send_reschedule = native_smp_suppress_reschedule; +} + static void native_stop_other_cpus(int wait) { unsigned long flags; @@ -250,6 +260,7 @@ static void native_stop_other_cpus(int wait) local_irq_save(flags); disable_local_APIC(); mcheck_cpu_clear(this_cpu_ptr(&cpu_info)); + native_smp_to_up(); local_irq_restore(flags); } --- If the system is not SMP anymore (hlt non-panic CPUs) - rewrite some smp_ops pointers to NOOP stubs to suppress some of those warnings. I know it's utterly awful. -ss