Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   John Ogness <john.ogness@linutronix.de>
To:     Steven Rostedt <rostedt@goodmis.org>,
        Petr Mladek <pmladek@suse.com>
Cc:     Sergey Senozhatsky <senozhatsky@chromium.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-kernel@vger.kernel.org,
        Stephen Rothwell <sfr@canb.auug.org.au>,
        Andrew Morton <akpm@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Stephen Boyd <swboyd@chromium.org>,
        Alexander Potapenko <glider@google.com>
Subject: Re: [PATCH next v4 1/2] lib/dump_stack: move cpu lock to printk.c
In-Reply-To: <20210618122541.49fbd114@oasis.local.home>
References: <20210617095051.4808-1-john.ogness@linutronix.de> <20210617095051.4808-2-john.ogness@linutronix.de> <20210617093243.795b4853@gandalf.local.home> <YMyyCwMt549micJE@alley> <20210618122541.49fbd114@oasis.local.home>
Date:   Sat, 19 Jun 2021 02:28:13 +0206
Message-ID: <87czsiog96.fsf@jogness.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On 2021-06-18, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 18 Jun 2021 16:47:39 +0200 Petr Mladek <pmladek@suse.com> wrote:
>> My understanding is that early_printk() is used only for very early
>> boot message in plain kernel. And that there is not much concurrency
>> at that time.
>
> It will continue if you use ",keep" option. And that is something I
> have done without Peter's patches, but then they become illegible when
> there's a bug if more than one CPU triggers.

Note that using "keep" to force some boot consoles to regular consoles
does not mean that early_printk() is used. Your suggestion of adding the
cpu lock to early_printk() will not help for the "keep" scenario.

>> That said. I always wanted to upstream Peter's patchset. But I never
>> found time to clean it up.

The main problem with Peter's patchset (aside from using unsafe
early_printk code in a preemptive environment) is that it does not
handle CONT messages. While I'm sure this is fine for Peter, it is quite
horrible for things like lockdep output.

It would not be too much work to implement an early_printk printing loop
as a reader of the ringbuffer. But that is basically what the upcoming
atomic console and sync mode will be doing. Once that code is available,
it would be trivial to allow early_printk usage if an atomic console is
not available.

My recommendation right now is wait a bit longer on the early_printk
hack. We are not far the atomic console and sync mode series (which come
immediately after the safe buffer removal series that we are currently
pushing).

John Ogness