linux-kernel - Re: [PATCH printk v1 06/10] printk: use seqcount_latch for console

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <YS2cdfN5/D1Jzelg@google.com>
Date:   Tue, 31 Aug 2021 12:05:25 +0900
From:   Sergey Senozhatsky <senozhatsky@...omium.org>
To:     Petr Mladek <pmladek@...e.com>
Cc:     John Ogness <john.ogness@...utronix.de>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH printk v1 06/10] printk: use seqcount_latch for
 console_seq

On (21/08/06 17:56), Petr Mladek wrote:
> 
> A solution might be to implement a generic cycle that would use
> the right latched_seq and buffers. Something like:
> 
> enum console_mode {
> 	CONSOLE_MODE_NORMAL = 0,
> 	CONSOLE_MODE_ATOMIC,
> 	CONSOLE_MODE_ATOMIC_NMI,
> 	CONSOLE_MODE_REPLAY_ALL,
> 	CONSOLE_MODE_LAST
> };
> 
> struct console_mode_info
> {
> 	static char text[CONSOLE_LOG_MAX];
> 	static char ext_text[CONSOLE_EXT_LOG_MAX];
> 	static struct latched_seq seq;
> };

Seems to me like this wants to be part of struct console.

[..]

> Problems:
> 
>    a) The same line might be printed by more contexts.
>    b) per-console kthreads?
> 
> 
> Ad a) I am not sure if we could prevent duplicated lines when
>       the nested IRQ/NMI writes the same message that is just
>       being written by the outer context. But it should be
>       an acceptable corner case.
> 
> Ad b) Everything will get much more complicated with per-console
>       kthreads. We will need counters and buffers for each console
>       and each context.

Oh, yes, you are talking about per-console counters/buffers too.

> This is what I was able to come up before leaving for vacation. I am
> not sure if it is the best design/naming and it if it has a chance
> to work.
> 
> But it looks like a way how to re-use the same code in all modes.
> It might help to see what is the same and what is special about each
> mode.
> 
> 
> I would prefer to see something like this instead of the completely
> different code paths for atomic consoles that are proposed by 7th
> patch of this patchset.

I agree.