Re: [PATCH] MAINTAINERS: Add printk maintainers

[Petr Mladek <pmladek@suse.com>]

On Thu 2016-12-15 08:48:15, Steven Rostedt wrote:
> On Thu, 15 Dec 2016 11:47:58 +0100
> Petr Mladek <pmladek@suse.com> 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
> 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@goodmis.org>

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@goodmis.org>

Thanks a lot for your input.

Best Regards,
Petr