All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.