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 23:00:01 +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 22:28, Steven Rostedt wrote:
> What I would suggest doing is create your own buffer to store the output.
> Then use the seq_buf() operations and such to print to that buffer, and
> then be able to read that output from something like a debug filesystem, or
> some user space daemon that will write to syslog.

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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ