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;
From:   John Ogness <john.ogness@linutronix.de>
To:     Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>
Cc:     Petr Mladek <pmladek@suse.com>,
        Sergey Senozhatsky <senozhatsky@chromium.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Linus Torvalds <torvalds@linuxfoundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        Daniel Vetter <daniel@ffwll.ch>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Helge Deller <deller@gmx.de>,
        Jason Wessel <jason.wessel@windriver.com>,
        Daniel Thompson <daniel.thompson@linaro.org>,
        John Kacur <jkacur@redhat.com>,
        "John B. Wyatt IV" <jbwyatt4@gmail.com>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: printk meeting at LPC 2022
In-Reply-To: <87h71cr1gb.fsf@jogness.linutronix.de>
References: <20220910221947.171557773@linutronix.de>
 <87h71cr1gb.fsf@jogness.linutronix.de>
Date:   Fri, 23 Sep 2022 16:55:28 +0206
Message-ID: <875yheqh6v.fsf@jogness.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Hi,

On 2022-09-12, John Ogness <john.ogness@linutronix.de> wrote:
> We now have a room/timeslot [0] where Thomas and I will be presenting
> and discussing this new approach [1] for bringing kthread and atomic
> console printing to the kernel.

Thanks to everyone who attended the meeting (in person and virtually)!
It was a productive and fun discussion that left me thinking we will get
the printk threading right this time.

Here are the main points that I took away from the meeting:

- Printing the backlog is important! If some emergency situation occurs,
  make sure the backlog gets printed.

- When an emergency occurs, put the full backtrace into the ringbuffer
  before flushing any backlog. This ensures that the backtrace makes it
  into the ringbuffer in case a panic occurs while flushing the backlog.

- A newline should be added when an atomic console takes over from a
  threaded console. This improves readability. We may decide later that
  the atomic console prints some extra information upon takeover, or
  that it completes the line the threaded console was printing. But for
  now we will just use a newline to keep things simple.

- It should be visible to users and in crash reports if legacy consoles
  were in use. It was suggested that a new TAINT flag could be used for
  this.

- There will need to be new console flags introduced so that safe
  printing decisions can be made in emergency and panic situations.

  For example, upon panic, intially only the consoles marked RELIABLE
  would be used. If any of the RELIABLE consoles required a hostile
  takeover, they would only be used if they are labeled to support safe
  hostile takeovers.

  All other consoles could then be tried as a "last hope" at the very
  end of panic(), after all records have been flushed to reliable
  consoles and when it no longer matters if a console kills the CPU. For
  non-panic emergencies (warn, rcu stalls, etc), there may be other
  flags that would be needed.

  Initially we do not plan to have any such flags. We can add them on an
  as-needed basis as console drivers are moved over to the new
  thread/atomic interface.

If I have missed anything relevant, please let me know.

John Ogness

> [0] https://lpc.events/event/16/contributions/1394/
> [1] https://lore.kernel.org/all/20220910221947.171557773@linutronix.de/