[PATCH] MAINTAINERS: Add printk maintainers

[PATCH] MAINTAINERS: Add printk maintainers

[Petr Mladek]

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
    + 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.

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.

Signed-off-by: Petr Mladek <pmladek@suse.com>
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c77e3bff262f..d8398bede04e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9728,6 +9728,13 @@ S:	Supported
 F:	Documentation/preempt-locking.txt
 F:	include/linux/preempt.h
 
+PRINTK
+M:	Petr Mladek <pmladek@suse.com>
+M:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
+S:	Maintained
+F:	kernel/printk/
+F:	include/linux/printk.h
+
 PRISM54 WIRELESS DRIVER
 M:	"Luis R. Rodriguez" <mcgrof@gmail.com>
 L:	linux-wireless@vger.kernel.org
-- 
1.8.5.6

Re: [PATCH] MAINTAINERS: Add printk maintainers

[Steven Rostedt]

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

>     + 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>

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

But anyway...

Acked-by: Steven Rostedt <rostedt@goodmis.org>


-- Steve

> 
> Signed-off-by: Petr Mladek <pmladek@suse.com>
> ---
>  MAINTAINERS | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c77e3bff262f..d8398bede04e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9728,6 +9728,13 @@ S:	Supported
>  F:	Documentation/preempt-locking.txt
>  F:	include/linux/preempt.h
>  
> +PRINTK
> +M:	Petr Mladek <pmladek@suse.com>
> +M:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> +S:	Maintained
> +F:	kernel/printk/
> +F:	include/linux/printk.h
> +
>  PRISM54 WIRELESS DRIVER
>  M:	"Luis R. Rodriguez" <mcgrof@gmail.com>
>  L:	linux-wireless@vger.kernel.org

Re: [PATCH] MAINTAINERS: Add printk maintainers

[Petr Mladek]

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

Re: [PATCH] MAINTAINERS: Add printk maintainers

[Peter Zijlstra]

On Thu, Dec 15, 2016 at 03:34:43PM +0100, Petr Mladek wrote:
> 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.

I find the occasional deadlock much preferable to guaranteed no output.

Re: [PATCH] MAINTAINERS: Add printk maintainers

[Steven Rostedt]

On Thu, 15 Dec 2016 18:12:00 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, Dec 15, 2016 at 03:34:43PM +0100, Petr Mladek wrote:
> > 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.  
> 
> I find the occasional deadlock much preferable to guaranteed no output.

Right, we can't stress the importance of getting output out when it
happens. A printk dump is the first course of action when debugging a
crash. And the printk output shows how much progress the computer made.

If all printks are asynchronous, that will be unreliable information.
And really, that information can be extremely useful, but only if it is
reliable, otherwise, it becomes useless.

-- Steve

Re: [PATCH] MAINTAINERS: Add printk maintainers

[Peter Zijlstra]

On Thu, Dec 15, 2016 at 12:20:27PM -0500, Steven Rostedt wrote:
> On Thu, 15 Dec 2016 18:12:00 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Thu, Dec 15, 2016 at 03:34:43PM +0100, Petr Mladek wrote:
> > > 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.  
> > 
> > I find the occasional deadlock much preferable to guaranteed no output.
> 
> Right, we can't stress the importance of getting output out when it
> happens. A printk dump is the first course of action when debugging a
> crash. And the printk output shows how much progress the computer made.
> 
> If all printks are asynchronous, that will be unreliable information.

No, that will be _no_ information, since the 'later' part that does the
flush will never happen.

> And really, that information can be extremely useful, but only if it is
> reliable, otherwise, it becomes useless.

Well, if you want reliable get a UART and those 3 patches I did to force
early_printk :-)

Re: [PATCH] MAINTAINERS: Add printk maintainers

[Steven Rostedt]

On Thu, 15 Dec 2016 18:23:36 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
 
> > If all printks are asynchronous, that will be unreliable information.  
> 
> No, that will be _no_ information, since the 'later' part that does the
> flush will never happen.

I meant what would be unreliable, is that the printk that was last
shown will not be the last printk that was called. I'm sure you may get
some printks. But not those that were queued and not printed when the
bug happens. But I think we are just saying the same thing.

> 
> > And really, that information can be extremely useful, but only if it is
> > reliable, otherwise, it becomes useless.  
> 
> Well, if you want reliable get a UART and those 3 patches I did to force
> early_printk :-)
> 

I have my own version too ;-)  But yours is a bit cleaner than mine, so
I may take them instead. I believe the force early_printk is in the -rt
patchset. We just need the locking code in there too.

-- Steve