Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220830145004.430545-1-daniel.vetter@ffwll.ch> <YxCY57DmFfTuHs1q@alley>
In-Reply-To: <YxCY57DmFfTuHs1q@alley>
From:   Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu, 1 Sep 2022 21:26:27 +0200
Message-ID: <CAKMK7uFwJumoLCddSxtd=tPoV1xLFw5uCWpY+WDtiRC=fiSedg@mail.gmail.com>
Subject: Re: [PATCH] kernel/panic: Drop unblank_screen call
To:     Petr Mladek <pmladek@suse.com>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        DRI Development <dri-devel@lists.freedesktop.org>,
        Daniel Vetter <daniel.vetter@intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jirislaby@kernel.org>,
        =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>,
        Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
        Xuezhi Zhang <zhangxuezhi1@coolpad.com>,
        Yangxi Xiang <xyangxi5@gmail.com>,
        nick black <dankamongmen@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Luis Chamberlain <mcgrof@kernel.org>,
        "Guilherme G. Piccoli" <gpiccoli@igalia.com>,
        Marco Elver <elver@google.com>,
        John Ogness <john.ogness@linutronix.de>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        David Gow <davidgow@google.com>,
        tangmeng <tangmeng@uniontech.com>,
        Tiezhu Yang <yangtiezhu@loongson.cn>,
        Chris Wilson <chris@chris-wilson.co.uk>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, 1 Sept 2022 at 13:35, Petr Mladek <pmladek@suse.com> wrote:
>
> 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.

Ah, that's a good piece of information that I didn't figure out.

Greg, if you haven't baked in the patch yet, can you perhaps add the
above information from Petr to the commit message?

Thanks, Daniel

>
>
> > 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@intel.com>
>
> Nice analyze. The change makes perfect sense from my POV:
>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
>
> Best Regards,
> Petr


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch