From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Feng Tang <feng.tang@intel.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Petr Mladek <pmladek@suse.com>,
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 <rostedt@goodmis.org>,
Sasha Levin <sashal@kernel.org>, Andi Kleen <ak@linux.intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: + panic-avoid-the-extra-noise-dmesg.patch added to -mm tree
Date: Tue, 11 Dec 2018 17:00:43 +0900 [thread overview]
Message-ID: <20181211080043.GA521@jagdpanzerIV> (raw)
In-Reply-To: <20181210094554.z5n7dmkrnlcpygg4@shbuild888>
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
prev parent reply other threads:[~2018-12-11 8:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-04 7:15 + panic-avoid-the-extra-noise-dmesg.patch added to -mm tree akpm
2018-12-04 10:10 ` Sergey Senozhatsky
2018-12-04 10:20 ` Petr Mladek
2018-12-04 15:49 ` Feng Tang
2018-12-04 16:01 ` Petr Mladek
2018-12-05 1:53 ` Feng Tang
2018-12-05 2:50 ` Sergey Senozhatsky
2018-12-05 3:05 ` Sergey Senozhatsky
2018-12-05 3:27 ` Feng Tang
2018-12-05 2:26 ` Sergey Senozhatsky
2018-12-05 2:47 ` Feng Tang
2018-12-05 2:57 ` Sergey Senozhatsky
2018-12-05 5:29 ` Sergey Senozhatsky
2018-12-05 8:00 ` Sergey Senozhatsky
2018-12-05 15:46 ` Feng Tang
2018-12-06 3:58 ` Feng Tang
2018-12-07 9:50 ` Sergey Senozhatsky
2018-12-10 9:45 ` Feng Tang
2018-12-10 15:57 ` Petr Mladek
2018-12-11 8:07 ` Sergey Senozhatsky
2018-12-11 8:22 ` Petr Mladek
2018-12-11 8:26 ` Sergey Senozhatsky
2018-12-11 8:32 ` Feng Tang
2018-12-11 9:08 ` Sergey Senozhatsky
2018-12-11 8:00 ` Sergey Senozhatsky [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181211080043.GA521@jagdpanzerIV \
--to=sergey.senozhatsky.work@gmail.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=bp@suse.de \
--cc=feng.tang@intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mm-commits@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sashal@kernel.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox