linux-kernel - Re: [PATCH 1/4] printk: Introduce per-console loglevel setting

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:   Thu, 14 Mar 2019 23:12:49 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Calvin Owens <calvinowens@...com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org,
        linux-serial@...r.kernel.org
Subject: Re: [PATCH 1/4] printk: Introduce per-console loglevel setting

Petr Mladek wrote:
> It might be even more straightforward when the per-console value
> defines the effective console level. I mean the following semantic:
> 
>    + "console_loglevel" would define the default loglevel used
>      by consoles at runtime.
> 
>    + the per-console loglevel could override the default
>      console_loglevel.
> 
>    + We would need a custom handler for the sysctl "console_loglevel".
>      It would write the given value to the global console_loglevel
>      variable and for all already registered consoles (con->loglevel).

But some functions change console_loglevel without sysctl (e.g.
console_verbose() when reporting hung tasks and panic()). Should
con->loglevel be changed (which might result in too much messages to
slow consoles) when console_loglevel changes?

> 
>      The value will be used also for all newly registered consoles
>      when they do not have any custom one.
> 
> 
>    + The handler for "loglevel" early param should behave the same
>      as the sysctl handler.
> 
> 
> IMHO, there is no perfect solution. The advantage of the above
> proposal is that you "see" and "use" exactly what you "set".