From: Feng Tang <feng.tang@intel.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: 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: Mon, 10 Dec 2018 17:45:54 +0800 [thread overview]
Message-ID: <20181210094554.z5n7dmkrnlcpygg4@shbuild888> (raw)
In-Reply-To: <20181207095004.GB3729@jagdpanzerIV>
Hi Sergey,
+ lkml.
On Fri, Dec 07, 2018 at 06:50:04PM +0900, Sergey Senozhatsky wrote:
> On (12/06/18 11:58), Feng Tang wrote:
> > > Same here, I tried on several platforms and hardly get the sysrq magic key
> > > working, though it works while system is running.
> > >
> > > And it make me wondering if those workqueue dependent led blinking code
> > > can still really work.
> >
> > Also, IMHO, if we need a panic blink method, it should better be simple
> > and robust with only HW registers access plus delay function, as I'm not
> > sure if the scheduling can still work.
> >
> > Anyway, can I propose to make the "local_irq_enable" conditional and off
> > by default, and add a warning.
>
> I'm not sure what to do about this. I think that the behaviour is platform
> specific. For instance, arm64 keeps secondary CPUs in a busy loop
> while (1)
> cpu_relax();
Yes, it's similar to x86's handling for non-panic CPU.
>
> (masked out) and on panic_cpu disables only SDEI (interrupts from firmware,
> if I got it right); so it seems that arm64 can handle IRQs after panic. And
> if there are platforms that handle IRQ (including sysrq) after panic, then
> both options - making printk a noop or keeping local irqs off - maybe can
> cause some problems. Or maybe not. We better ask arch people.
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?
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.
Thanks,
Feng
>
> Personally, on my x86 laptop, I'd prefer the srollback to work after panic.
> Just my 5 cents.
>
> -ss
next prev parent reply other threads:[~2018-12-10 9:45 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 [this message]
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
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=20181210094554.z5n7dmkrnlcpygg4@shbuild888 \
--to=feng.tang@intel.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=bp@suse.de \
--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.work@gmail.com \
--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