linux-kernel - Re: [PATCH] MAINTAINERS: Add printk maintainers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161215143443.GA1053@pathway.suse.cz>
Date:   Thu, 15 Dec 2016 15:34:43 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MAINTAINERS: Add printk maintainers

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

Thanks a lot for your input.

Best Regards,
Petr