linux-kernel - Re: [RFC/PATCH] printk: Fix preferred console selection with multiple matches

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: <0511b917d8ebcf594480349b79fcb9f14aa882f9.camel@kernel.crashing.org>
Date:   Mon, 16 Dec 2019 11:09:33 +1100
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     Petr Mladek <pmladek@...e.com>
Cc:     linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        AlekseyMakarov <aleksey.makarov@...aro.org>
Subject: Re: [RFC/PATCH] printk: Fix preferred console selection with
 multiple matches

On Wed, 2019-12-11 at 10:17 +0100, Petr Mladek wrote:
> The reverse search of list of console does not work for ttySX
> consoles because the number is omitted when matching. And the messages
> will appear only on the first matched serial console. There is
> a paragraph about this in the commit message of my patch.

About that specific issue...

I see indeed that 8250_core.c registers a "generic" console with index
-1 which will match whetever we hit first in the array.

This is actually wrong isn't it ? Without any change such as what we've
been proposing, it means that an arch doing add_preferred_console of
any ttyS* will override anything on the command line, and it also means
that a command line with multiple ttyS entries will stop at the first
one, not the last one.

IE. In both case the code will select a console that isn't
preferred_console... or am I missing something subtle ?

So yes, fixing that will "regress" in the sense that it will change the
behaviour, but to make it match what's documented... am I wrong ?

The question then becomes what's the most broken ? Changing the
behaviour that might have become expected or leaving the (alledgedly)
broken behaviour in place ?

Cheers,
Ben.