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
> >
> > 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
> needed".

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
> reviewer:
> 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
> himself.

It would be much appreciated as well.

> But anyway...
> Acked-by: Steven Rostedt <rostedt@xxxxxxxxxxx>

Thanks a lot for your input.

Best Regards,