linux-kernel - Re: [PATCH printk v3 00/15] printk/for-next

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: <20220421144025.GE11747@pathway.suse.cz>
Date:   Thu, 21 Apr 2022 16:40:25 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Alexander Potapenko <glider@...gle.com>,
        Stephen Boyd <swboyd@...omium.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Nicholas Piggin <npiggin@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Neeraj Upadhyay <quic_neeraju@...cinc.com>,
        Josh Triplett <josh@...htriplett.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Helge Deller <deller@....de>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Xiaoming Ni <nixiaoming@...wei.com>,
        Marco Elver <elver@...gle.com>, Wei Liu <wei.liu@...nel.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Mark Brown <broonie@...nel.org>,
        Shawn Guo <shawn.guo@...aro.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        Wang Qing <wangqing@...o.com>, rcu@...r.kernel.org
Subject: Re: [PATCH printk v3 00/15] printk/for-next

On Wed 2022-04-20 01:52:22, John Ogness wrote:
> This is v3 of a series to implement a kthread for each registered
> console. v2 is here [0]. The kthreads locklessly retrieve the
> records from the printk ringbuffer and also do not cause any lock
> contention between each other. This allows consoles to run at full
> speed. For example, a netconsole is able to dump records much
> faster than a serial or vt console. Also, during normal operation,
> printk() callers are completely decoupled from console printing.
> 
> There are situations where kthread printing is not sufficient. For
> example, during panic situations, where the kthreads may not get a
> chance to schedule. In such cases, the current method of attempting
> to print directly within the printk() caller context is used. New
> functions printk_prefer_direct_enter() and
> printk_prefer_direct_exit() are made available to mark areas of the
> kernel where direct printing is preferred. (These should only be
> areas that do not occur during normal operation.)
> 
> This series also introduces pr_flush(): a might_sleep() function
> that will block until all active printing threads have caught up
> to the latest record at the time of the pr_flush() call. This
> function is useful, for example, to wait until pending records
> are flushed to consoles before suspending.
> 
> Note that this series does *not* increase the reliability of console
> printing. Rather it focuses on the non-interference aspect of
> printk() by decoupling printk() callers from printing (during normal
> operation). Nonetheless, the reliability aspect should not worsen
> due to this series.

This series looks almost ready for linux-next. The only real
problems are:

   + Use allow_direct_printing() instead of
     atomic_read(&printk_prefer_direct) in defer_console_output()

   + "temporary" remove
     console_lock_single_hold()/console_lock_single_release() and
     use the full console_lock()/console_unlock() instead.

The rest are few cosmetic issues.

I would like to push this into linux-next ASAP so that we get some
wider testing of this approach. I do not expect that we could find
much more issues just by staring into the code ;-)

Now, the question is whether I should wait for v4. Or whether
I should put v3 into linux-next with a follow up patch doing
the two above suggested changes. They are quite trivial.

Anyway, if I pushed v3+fixup then I would replace it with v4, v5, ...
once they are available. I just do not want to block testing because
of cosmetic problems.

John, what is your preference, please?
Anybody has another opinion, please?

Best Regards,
Petr