linux-kernel - Re: [PATCH] printk: stop spining waiter when console resume to flush prb

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: <871raeop5q.fsf@jogness.linutronix.de>
Date:   Mon, 10 May 2021 12:32:01 +0200
From:   John Ogness <john.ogness@...utronix.de>
To:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <senozhatsky@...omium.org>
Cc:     Luo Jiaxing <luojiaxing@...wei.com>, sergey.senozhatsky@...il.com,
        rostedt@...dmis.org, linux-kernel@...r.kernel.org,
        linuxarm@...wei.com, bobo.shaobowang@...wei.com
Subject: Re: [PATCH] printk: stop spining waiter when console resume to flush prb

On 2021-05-10, Petr Mladek <pmladek@...e.com> wrote:
> The current plan is to move console work to kthreads (separate
> preemptive context). Using IRQ is a complete opposite way.
>
> There is always the fight between getting the messages out as soon
> as possible and the risk of breaking the system (softlockups,
> deadlocks).
>
> The kthread approach reduces the risk of system breakage to a bare
> minimum. The price is that some messages might never reach console.
> There is finally a consensus to give it a try. If it fails, we might
> start looking for alternatives again.

+1

I think it is clear that any such fixups will disappear once
atomic-consoles and console printing kthreads arrive. That doesn't mean
we should ignore the fixups. We just need to decide if it is a real
problem that needs our immediate attention, thus warranting a fixup in
the current implementation.

I can see the suspend/resume issue might be a real problem. If this
should be addressed now, I would support Petr's patch, forcing the
backlog to be printed in the preemptible resuming context. But let's
just keep it a suspend/resume fixup. I do not think we want to start
playing with how console_unlock() behaves.

John Ogness