linux-kernel - Re: [PATCH v2] printk: allow direct console printing to be enabled always

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: <875yktadtr.fsf@jogness.linutronix.de>
Date:   Tue, 21 Jun 2022 23:53:44 +0206
From:   John Ogness <john.ogness@...utronix.de>
To:     Sergey Senozhatsky <senozhatsky@...omium.org>
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        Petr Mladek <pmladek@...e.com>, Marco Elver <elver@...gle.com>,
        linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v2] printk: allow direct console printing to be enabled
 always

On 2022-06-20, Sergey Senozhatsky <senozhatsky@...omium.org> wrote:
> would it make sense/be possible/etc. to look into possibility
> to address that "deferred kthread vs IRQ" race by moving prb entries
> emit to the same IRQ handler that emits chars from uart xmit buffer?

I think this is an interesting idea. We could have a function that would
allow serial drivers (if they had a console on them) to flush any
pending printk messages for their console.

Each driver would need to call this function for themselves. And also
the driver would need to ensure that it is not holding any locks that
the console-part of the driver will need. And it would need to be best
effort, because the related kthread may already be in the process of
printing. But in general I think it could be a nice feature to improve
the sort-of-synchronous behavior of printk for drivers that use it.

John Ogness