linux-kernel - Re: [PATCH] printk: Add loglevel for "do not print to consoles".

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]

Date:   Fri, 24 Apr 2020 10:31:31 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        linux-kernel@...r.kernel.org, Dmitry Safonov <dima@...sta.com>,
        Michal Hocko <mhocko@...e.com>,
        Yafang Shao <laoar.shao@...il.com>
Subject: Re: [PATCH] printk: Add loglevel for "do not print to consoles".

On Fri, 24 Apr 2020 23:00:01 +0900
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp> wrote:

> Since KERN_NO_CONSOLES is for -ENOMEM situations (GFP_KERNEL allocation which
> can sleep needs to invoke the OOM killer, or GFP_ATOMIC allocation which cannot
> sleep has failed), we can't create buffer on demand. For process context, it
> would be possible to create buffer upon fork() time. But for atomic context,
> it is so difficult to create buffer on demand. We could allocate shared buffer
> like logbuf but it means that we have to replicate what printk() is doing (too
> much code), for when atomic memory allocation happens resembles when printk()
> is called. Borrowing printk()'s logbuf is simpler.

I would have a buffer allocated for this at start up.

What exactly would you be "replicating" in printk? The point of printk is
to print to a console, not to be a generic ring buffer. This change is
breaking printk's most useful feature.

-- Steve