On Wed 29-04-20 01:23:15, Tetsuo Handa wrote:
> On 2020/04/29 0:45, Michal Hocko wrote:
> > On Tue 28-04-20 22:11:19, Tetsuo Handa wrote:
> >> Existing KERN_$LEVEL allows a user to determine whether he/she wants that
> >> message
> >> to be printed on consoles (even if it spams his/her operation doing on
> >> consoles), and
> >> at the same time constrains that user whether that message is saved to log
> >> files.
> >> KERN_NO_CONSOLES allows a user to control whether he/she wants that
> >> message to be
> >> saved to log files (without spamming his/her operation doing on consoles).
> >
> > I understand that. But how do I know whether the user considers the
> > particular information important enough to be dumped on the console.
> > This sounds like a policy in the kernel to me.
>
> I'm still unable to understand your question.
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.
> > I simply cannot forsee
> > any console configuration to tell whether my information is going to
> > swamp the console to no use or not.
>
> Neither can I.
>
> > Compare that to KERN_$LEVEL instead.
> > I know that an information is of low/high importance. It is the user
> > policy to decide and base some filtering on top of that priority.
>
> Whether to use KERN_NO_CONSOLES is not per-importance basis but per-content
> basis.
>
> Since both pr_info("[%7d] %5d %5d %8lu %8lu %8ld %8lu %5hd %s\n",
> ...) from dump_tasks() and
> pr_info("oom-kill:constraint=%s,nodemask=%*pbl", ...) from dump_oom_summary()
> use KERN_INFO importance,
> existing KERN_$LEVEL-based approach cannot handle these messages differently.
> Since changing the former to
> e.g. KERN_DEBUG will cause userspace to discard the messages, we effectively
> can't change KERN_$LEVEL.
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.
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 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. You can fine tune
priorities and that is all right because they should be reflecting
importance. 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.
--
Michal Hocko
SUSE Labs
