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: <20220621135533.GF7891@pathway.suse.cz>
Date:   Tue, 21 Jun 2022 15:55:33 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Daniel Palmer <daniel@...f.com>,
        John Ogness <john.ogness@...utronix.de>,
        Marek BehĂșn <kabel@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Jan Kara <jack@...e.cz>, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v2] printk/console: Enable console kthreads only when
 there is no boot console left

On Tue 2022-06-21 07:45:09, Linus Torvalds wrote:
> On Tue, Jun 21, 2022 at 6:42 AM Daniel Palmer <daniel@...f.com> wrote:
> >
> > The lockups on boot seem to be gone on my boards with this patch.
> 
> Good.
> 
> Petr, was this all the reports sorted out? Sounds like we can keep the
> kernel thread model.

Yes, it seems that we fixed all the reports when boot failed or
the console was messed or silent.

There is one more issue, see
https://lore.kernel.org/r/YqyANveL50uxupfQ@zx2c4.com
It is about synchronization between messages printed by
userspace and kernel consoles.

The synchronization was never guaranteed. I think that it is
not an argument to remove the kthreads. They are really
needed, especially for huge systems, noisy debugging,
or RT where softlockups really hurts.

My opinion is that we might easily support 3 printk
modes, switched on the command line:

1. Use printk console kthreads when the system is normally
   running. It makes printk() predictable and safe. We do
   our best to switch to the direct mode when the kthreads
   are not reliable, for example, panic, suspend, reboot.

   IMHO, it should be default, especially for production
   systems.


2. Use an atomic console in fully synchronous mode. It is
   inspired by a patch from Peter Zijlstra. It calls
   the (serial) console directly from printk() and
   uses CPU-reentrant lock to serialize the messages
   between CPUs.

   AFAIK, Peter and some others use this approach to
   debug some nasty bugs in the scheduler, NMI,
   early boot when even the legacy code using
   console_lock() is not reliable enough.

   John Ogness is working on the atomic serial console.
   It would allow to integrate this mode a clean
   way.

   It is not usable for production because printk()
   might slow down the entire system.


3. Use the legacy code that tries to call consoles from
   printk() via console_trylock(). We need this code
   anyway for the early boot, suspend, reboot, panic.

   It would be used for debugging nasty bugs like
   the 2nd mode for system without serial console.
   It will be pretty hard to create lockless
   variant for more complicate consoles.


I am not happy that we need more modes. But I think that
they all have a good justification.


Best Regards,
Petr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ