linux-kernel - Re: [PATCH printk v2 08/26] printk: nbcon: Implement processing in port->lock wrapper

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: <87r0fwt3z4.fsf@jogness.linutronix.de>
Date: Wed, 27 Mar 2024 10:38:15 +0106
From: John Ogness <john.ogness@...utronix.de>
To: Tony Lindgren <tony@...mide.com>
Cc: Petr Mladek <pmladek@...e.com>, Sergey Senozhatsky
 <senozhatsky@...omium.org>, Steven Rostedt <rostedt@...dmis.org>, Thomas
 Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org, Greg
 Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby
 <jirislaby@...nel.org>, Ilpo Järvinen
 <ilpo.jarvinen@...ux.intel.com>,
 Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Geert Uytterhoeven
 <geert+renesas@...der.be>, Justin Chen <justin.chen@...adcom.com>, Jiaqing
 Zhao <jiaqing.zhao@...ux.intel.com>, linux-serial@...r.kernel.org, Peter
 Collingbourne <pcc@...gle.com>
Subject: Re: [PATCH printk v2 08/26] printk: nbcon: Implement processing in
 port->lock wrapper

On 2024-03-22, Tony Lindgren <tony@...mide.com> wrote:
> * John Ogness <john.ogness@...utronix.de> [240313 09:50]:
>> One nice thing that has risen from this is we are starting to see
>> exactly what the console lock is needed for. At this point I would say
>> its main function is synchronizing boot consoles with real
>> drivers. Which means we will not be able to remove the console lock
>> until we find a real solution to match boot consoles (which circumvent
>> the Linux driver model) with the real drivers.
>
> Would it help if earlycon handles all the boot consoles?
> Then just have the serial driver take over when it probes?

I think this would be very helpful. And it would also cleanup the boot
arguments. For example, we would no longer need the
architecture-specific arguments/options (such as "early_printk" and
"keep"). These architecture-specific arguments can be really
confusing. There have been so many times I see a developer cursing that
they can't get early debugging working, when I notice they are trying to
use "early_printk" on an arm64 system.

Browsing through

arch/x86/kernel/early_printk.c
arch/x86/boot/early_serial_console.c

you can see lots of examples of various early consoles and their special
tricks/hacks (such as pretending not to be a boot console when it really
is).

And pretty much every architecture has these. (git grep CON_BOOT)

Ideally it would be great if a console could register and say "taking
over for console X". Maybe with a new field:

struct console {
  ...
  struct console *console_to_replace;
  ...
};

John Ogness