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]
Date:   Fri, 18 Feb 2022 13:52:23 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     John Ogness <john.ogness@...utronix.de>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Josh Triplett <josh@...htriplett.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        Corey Minyard <cminyard@...sta.com>,
        Kees Cook <keescook@...omium.org>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Mark Brown <broonie@...nel.org>,
        Josef Bacik <josef@...icpanda.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Shawn Guo <shawn.guo@...aro.org>,
        Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Wang Qing <wangqing@...o.com>, Tejun Heo <tj@...nel.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Alexander Potapenko <glider@...gle.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Nicholas Piggin <npiggin@...il.com>,
        "rcu@...r.kernel.org" <rcu@...r.kernel.org>
Subject: Re: [PATCH printk v1 09/13] printk: add functions to allow direct
 printing

On Fri 2022-02-18 09:00:46, David Laight wrote:
> > On Mon 2022-02-07 20:49:19, John Ogness wrote:
> > > Once kthread printing is introduced, console printing will no longer
> > > occur in the context of the printk caller. However, there are some
> > > special contexts where it is desirable for the printk caller to
> > > directly print out kernel messages.
> 
> Yes - most of them.
> 
> It is going to be pretty impossible to do 'hard' kernel debugging
> if printk get deferred.

What do you exactly mean by 'hard' kernel debugging, please?
What exactly won't be possible, please?

It is really important to talk about real scenarios because we
do our best to address them. This patchset disables the deferred
console handling in several situations, especially during panic,
reboot, kexec. The consoles are flushed during suspend, etc.

The patchset solves real problems, soft and live-lockups and even
deadlocks.

It will actually allow debugging when too many messages caused
softlockups and the system died. I saw it many times during boot
of systems with many network interfaces or disks. Backtraces
from all CPUs and processes, detailed Oops reports, and similar
extensive output was able to kill the system.

In each case, the legacy "direct" mode will still be around.


> Typically there already is a deferral method.
> The prints aren't done by the kernel, but by syslogd.

syslogd helps only when userspace works and the messages
can be stored on a filesystems.

And it is perfectly fine and much more safe to defer consoles
most of the time. I have seen many reports where consoles put
the system into knees. And sometime printk() was the root of all
problems.

Best Regards,
Petr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ