[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YxCY57DmFfTuHs1q@alley>
Date: Thu, 1 Sep 2022 13:35:03 +0200
From: Petr Mladek <pmladek@...e.com>
To: Daniel Vetter <daniel.vetter@...ll.ch>
Cc: LKML <linux-kernel@...r.kernel.org>,
DRI Development <dri-devel@...ts.freedesktop.org>,
Daniel Vetter <daniel.vetter@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Xuezhi Zhang <zhangxuezhi1@...lpad.com>,
Yangxi Xiang <xyangxi5@...il.com>,
nick black <dankamongmen@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Luis Chamberlain <mcgrof@...nel.org>,
"Guilherme G. Piccoli" <gpiccoli@...lia.com>,
Marco Elver <elver@...gle.com>,
John Ogness <john.ogness@...utronix.de>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
David Gow <davidgow@...gle.com>,
tangmeng <tangmeng@...ontech.com>,
Tiezhu Yang <yangtiezhu@...ngson.cn>,
Chris Wilson <chris@...is-wilson.co.uk>
Subject: Re: [PATCH] kernel/panic: Drop unblank_screen call
On Tue 2022-08-30 16:50:04, Daniel Vetter wrote:
> console_unblank() does this too (called in both places right after),
> and with a lot more confidence inspiring approach to locking.
>
> Reconstructing this story is very strange:
>
> In b61312d353da ("oops handling: ensure that any oops is flushed to
> the mtdoops console") it is claimed that a printk(" "); flushed out
> the console buffer, which was removed in e3e8a75d2acf ("[PATCH]
> Extract and use wake_up_klogd()"). In todays kernels this is done way
> earlier in console_flush_on_panic with some really nasty tricks. I
> didn't bother to fully reconstruct this all, least because the call to
> bust_spinlock(0); gets moved every few years, depending upon how the
> wind blows (or well, who screamed loudest about the various issue each
> call site caused).
>
> Before that commit the only calls to console_unblank() where in s390
> arch code.
>
> The other side here is the console->unblank callback, which was
> introduced in 2.1.31 for the vt driver. Which predates the
> console_unblank() function by a lot, which was added (without users)
> in 2.4.14.3. So pretty much impossible to guess at any motivation
> here. Also afaict the vt driver is the only (and always was the only)
> console driver implementing the unblank callback, so no idea why a
> call to console_unblank() was added for the mtdooops driver - the
> action actually flushing out the console buffers is done from
> console_unlock() only.
My understanding is that mtdoops is not a real console. The commit
4b23aff083649eafa141 ("[MTD] oops and panic message logging to MTD
device") suggests that it was just (mis)using the console
infrastructure.
The commit 2e386e4bac90554887e73d ("mtd: mtdoops: refactor as a
kmsg_dumper") converted it to use the new kmsg_dumper API that
was created for this use case.
So, I would consider all the mtdoops-related changes as a misuse
of the console API.
> Note that as prep for the s390 users the locking was adjusted in
> 2.5.22 (I couldn't figure out how to properly reference the BK commit
> from the historical git trees) from a normal semaphore to a trylock.
>
> Note that a copy of the direct unblank_screen() call was added to
> panic() in c7c3f05e341a ("panic: avoid deadlocks in re-entrant console
> drivers"), which partially inlined the bust_spinlocks(0); call.
>
> Long story short, I have no idea why the direct call to unblank_screen
> survived for so long (the infrastructure to do it properly existed for
> years), nor why it wasn't removed when the console_unblank() call was
> finally added. But it makes a ton more sense to finally do that than
> not - it's just better encapsulation to go through the console
> functions instead of doing a direct call, so let's dare. Plus it
> really does not make much sense to call the only unblank
> implementation there is twice, once without, and once with appropriate
> locking.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@...el.com>
Nice analyze. The change makes perfect sense from my POV:
Reviewed-by: Petr Mladek <pmladek@...e.com>
Best Regards,
Petr
Powered by blists - more mailing lists