Re: [PATCH] MAINTAINERS: Add printk maintainers
From: Petr Mladek
Date: Thu Dec 15 2016 - 09:34:54 EST
On Thu 2016-12-15 08:48:15, Steven Rostedt wrote:
> On Thu, 15 Dec 2016 11:47:58 +0100
> Petr Mladek <pmladek@xxxxxxxx> wrote:
> > I and Sergey would like to volunteer as printk code maintainers.
> > It is a code that everyone is using, various people fix bugs or
> > even add features but there is nobody really interested into
> > maintaining it.
> > I and Sergey have put a lot of effort into understanding the code
> > and related problems. We are working on solutions for some long
> > term problems. There is a nice summary from the Kernel Summit
> > presentation, see https://lwn.net/Articles/705938/
> > We have already started to use the gained knowledge and comment
> > on other printk-related patches. The official role should help
> > us to do it more effectively.
> > Our priorities are:
> > + prevent deadlocks (printk_safe patchset, console locks)
> > + prevent softlocks (async printk, console_sem and flushing)
> > + handle other bugs/fixes/features as they come
> > with this in mind:
> > + printk is used in different context
> > + need special care in some modes, e.g. oops, panic, suspend
> > + do best effort to store/show messages
> Output immediately when they happen too. Perhaps we need a way to
> differentiate, "Show now" messages vs "This is info only, delay if
We have to find the right balance. For example, we do not show
messages immediately in NMI context because there is a risk
of a deadlock. We have to somehow limit it in IRQ context to
avoid a softlock. In fact, we must avoid "infinite" output
even in normal context to avoid a livelock.
It must be decently configurable because a more risky handling
might help to debug some corner-case bugs.
The async printk patchset is important here. It will allow to do
output in a safe context using a dedicated kthread. I am sure that
it will need some tuning. We could discuss it more once Sergey
sends new version, ...
> > + the code is already pretty complicated and twisted;
> > support clean ups; always think hard if a feature/fix
> > is worth any complication
> > Of course, it still will be much appreciated if other people review
> > printk patches.
> I don't have a problem with you maintaining this, but put me down as a
> R: Steven Rostedt <rostedt@xxxxxxxxxxx>
Definitely. This is great news!
> > Regarding the workflow. It will be highly appreciated if the patches
> > might still go via Andrew's -mm tree at least for 4.10. In the long
> > term, we would like to make Andrew's life easier and handle printk
> > patches in an own git tree. But we first need to set it up and get
> > familiar with the processes.
> Maybe Andrew should be a reviewer too. But I'll let him speak for
It would be much appreciated as well.
> But anyway...
> Acked-by: Steven Rostedt <rostedt@xxxxxxxxxxx>
Thanks a lot for your input.