From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=7mzl=OQ=gmail.com=sergey.senozhatsky.work@kernel.org>
Date: Fri, 7 Dec 2018 18:50:04 +0900
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>
Subject: Re: + panic-avoid-the-extra-noise-dmesg.patch added to -mm tree
Message-ID: <20181207095004.GB3729@jagdpanzerIV>
References: <20181204071531.z62N9NwXC%akpm@linux-foundation.org>
 <20181204102033.ltdvc7gmev2gvlkq@pathway.suse.cz>
 <20181204154936.wbgcovzpc54n6dvs@shbuild888>
 <20181205022654.GA503@jagdpanzerIV>
 <20181205024713.nqyt6qiamokq7qtl@shbuild888>
 <20181205025728.GC503@jagdpanzerIV>
 <20181205052912.GA423@jagdpanzerIV>
 <20181205080044.GA11190@jagdpanzerIV>
 <20181205154620.4dqtledc2duhrp2c@shbuild888>
 <20181206035825.jz2bfh3errj23rjq@shbuild888>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181206035825.jz2bfh3errj23rjq@shbuild888>
List-ID: <stable.vger.kernel.org>

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();

(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.

Personally, on my x86 laptop, I'd prefer the srollback to work after panic.
Just my 5 cents.

	-ss