Messages in this thread | | | From | John Ogness <> | Subject | Re: printk meeting at LPC 2022 | Date | Fri, 23 Sep 2022 16:55:28 +0206 |
| |
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/
| |