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]

Message-ID: <7ec0b0a3-39ae-0f1c-b8c2-e1e9e60f1223@i-love.sakura.ne.jp>
Date:   Sat, 25 Apr 2020 00:28:53 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Steven Rostedt <rostedt@...dmis.org>
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 2020/04/24 23:31, Steven Rostedt wrote:
> 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.

Allocating global buffer itself is simple (except that it might waste a lot of
memory). Difficult part is how to use the buffer.

> 
> What exactly would you be "replicating" in printk?

Making it possible to store into global buffer from almost any context (not only
process context but also softirq/hardirq/NMI context (well, is memory allocation
 from NMI context not permitted? I don't know... but future KERN_NO_CONSOLES
users might want to call from NMI context)), notify userspace program of data
readiness, and manage the buffer.

KERN_NO_CONSOLES does not need to call call_console_drivers(). But basically
things what printk() is doing.

>                                                    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.

For those who analyze log files (instead of console output), the point of
printk() is to save kernel messages into log files (via userspace syslog
daemon).

By the way, I think

  printk(KERN_NO_CONSOLES "hello\n")

is almost same with doing

  saved_loglevel = console_loglevel;
  console_loglevel = CONSOLE_LOGLEVEL_SILENT;
  printk("hello\n");
  console_loglevel = saved_loglevel;

used by vkdb_printf().