linux-kernel - Re: [PATCH v4 0/4] Fixes for console command line ordering

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: <2024062403-skid-gotten-7585@gregkh>
Date: Mon, 24 Jun 2024 15:35:39 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Petr Mladek <pmladek@...e.com>
Cc: Tony Lindgren <tony.lindgren@...ux.intel.com>,
	Linus Torvalds <torvalds@...uxfoundation.org>,
	Jiri Slaby <jirislaby@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	John Ogness <john.ogness@...utronix.de>,
	Sergey Senozhatsky <senozhatsky@...omium.org>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Tony Lindgren <tony@...mide.com>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 0/4] Fixes for console command line ordering

On Fri, Jun 21, 2024 at 04:44:10PM +0200, Petr Mladek wrote:
> Added Linus into Cc.
> 
> On Thu 2024-06-20 15:45:25, Tony Lindgren wrote:
> > Hi,
> > 
> > Recent changes to add support for DEVNAME:0.0 style consoles caused a
> > regression with the preferred console order where the last console on
> > the kernel command line is no longer the preferred console.
> > 
> > The following four changes fix the issue using Petr's suggestion that
> > does not involve calling __add_preferred_console() later on again, and
> > adds the deferred consoles to the console_cmdline[] directly to be
> > updated when the console is ready.
> > 
> > We revert the earlier printk related changes, and then add back the
> > DEVNAME:0.0 functionality based on Petr's code snippet. And we end up
> > reducing the code quite a bit too this way.
> > 
> > And we also revert all the unusable serial core console quirk handling,
> > it does not do anything for the legacy "ttyS" named consoles. And then
> > we add a minimal serial_base_match_and_update_preferred_console().
> > 
> > The reason we want DEVNAME:0.0 style consoles is it helps addressing the
> > console based on the connected serial port controller device rather than
> > using the hardcoded ttyS addressing. And that helps with issues related
> > to the console moving around after togging the HSUART option in the BIOS,
> > or when new ports are enabled in devicetree and aliases are not updated.
> > 
> > Tony Lindgren (4):
> >   printk: Revert add_preferred_console_match() related commits
> >   printk: Add match_devname_and_update_preferred_console()
> >   serial: core: Revert unusable console quirk handling
> >   serial: core: Add serial_base_match_and_update_preferred_console()
> > 
> >  drivers/tty/serial/8250/8250_core.c  |   5 -
> >  drivers/tty/serial/serial_base.h     |  22 +---
> >  drivers/tty/serial/serial_base_bus.c | 116 +++------------------
> >  drivers/tty/serial/serial_core.c     |   2 +-
> >  include/linux/printk.h               |   5 +-
> >  kernel/printk/Makefile               |   2 +-
> >  kernel/printk/conopt.c               | 146 ---------------------------
> >  kernel/printk/console_cmdline.h      |   7 +-
> >  kernel/printk/printk.c               | 122 ++++++++++++++++------
> >  9 files changed, 112 insertions(+), 315 deletions(-)
> >  delete mode 100644 kernel/printk/conopt.c
> 
> The patchset looks ready for linux-next. And I have pushed it
> into printk/linux.git, branch for-6.10-register-console-devname.
> 
> I am not sure about the mainline. We need to fix the regression in 6.10.
> The change is not trivial and rc5 is knocking on the doors.
> 
> Unfortunately, the patchset intermixes reverts and new code.
> So that it can't be used for simple revert as is.
> 
> I am quite confident that the new code works as expected.
> It changes tricky code but the logic of the change is quite
> straightforward.
> 
> 
> I see three solutions:
> 
> 1. Linus could merge the changes directly into rc5.
> 
> 2. I could send a pull request after it survives few days in
>    linux-next.
> 
> 3. Or we rework the patchset. And do pure revert for 6.10 and
>    add the feature a clean way for-6.11.

Pure revert for 6.10 might be good, as it's late in the cycle.  Let me
know the git ids and I can do that.

> I personally prefer the 3rd solution. But I am super conservative.
> I guess that most other people would go with the other 2 solutions.

I'll be conservative here as well.

thanks,

greg k-h