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

[Tetsuo Handa]

On 2020/04/29 23:21, Michal Hocko wrote:
> I am trying to say that KERN_NO_CONSOLES resembles more a policy than a
> priority. Because I as a developer have no idea whether the message is
> good enough for console or not.

Right, KERN_NO_CONSOLES is not a priority.

> I believe we are free to change kernel log levels as we find a fit. I
> was not aware that KERN_DEBUG messages are automatically filtered out.

Below is the default rules for rsyslog-8.24.0-52.el7 (userspace syslog daemon).
Of course administrators can modify as needed, but notice that KERN_INFO is saved
to /var/log/messages but KERN_DEBUG is saved to nowhere.

----------
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 :omusrmsg:*

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log
----------

> Even if this is the case then this doesn't really disallow admins to
> allow KERN_DEBUG into log files. Dump of the oom eligible tasks is
> arguably a debugging output anyway. So I disagree with your statement.

If dump_tasks() were changed to use KERN_DEBUG, administrators have to add
"kern.debug" rule (at the same time endure a lot of noise from KERN_DEBUG)
in order to record OOM victim candidates for later analysis.

> 
>> If the kernel allows the former to use KERN_NO_CONSOLES in addition to KERN_INFO, the administrator can
>> select from two choices: printing "both the former and the latter" or "only the latter" to consoles.
> 
> I am not really familiar with all the possibilities admins have when
> setting filtering for different consoles but KERN_NO_CONSOLES sounds
> rather alien to the existing priority based approach.

KERN_NO_CONSOLES is not a priority based approach.
KERN_NO_CONSOLES resembles CONSOLE_LOGLEVEL_SILENT.

>                                                       You can fine tune
> priorities and that is all right because they should be reflecting
> importance.

Developer's importance and administrator's interests are different. Any printk()
user is randomly selecting KERN_$LEVEL. Administrators are swayed by having to
record the lowest priority from all interested messages.

>             But global no-consoles doesn't really fit in here because
> each console might require a different policy but the marking is
> unconditional and largely unaware of existing consoles.

Why unconditional? I'm saying that users of KERN_NO_CONSOLES marking (in other
words, "whether the message is good enough for console or not") should be
configurable via e.g. sysctl. If administrators want to use per-console loglevel
setting, they can tell the kernel not to mark KERN_NO_CONSOLES via e.g. sysctl.