linux-kernel - Re: [RFC][PATCH 1/2] printk: Introduce per-console filtering of messages by loglevel

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: <20170406140251.GC27578@pathway.suse.cz>
Date:   Thu, 6 Apr 2017 16:02:51 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Calvin Owens <calvinowens@...com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Manuel Schölling <manuel.schoelling@....de>,
        Hans de Goede <hdegoede@...hat.com>,
        Paul Burton <paul.burton@...tec.com>,
        linux-kernel@...r.kernel.org, kernel-team@...com,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [RFC][PATCH 1/2] printk: Introduce per-console filtering of
 messages by loglevel

On Wed 2017-04-05 17:38:19, Calvin Owens wrote:
> On Wednesday 04/05 at 17:22 +0200, Petr Mladek wrote:
> > I think about a reasonable behavior. There seems to be three variables
> > that are related and are in use:
> > 
> >      console_level
> >      minimum_console_loglevel
> >      ignore_loglevel
> > 
> > The functions seems to be the following:
> > 
> >   + console_level defines the current maximum level of
> >     messages that appear on all enabled consoles; it
> >     allows to filter out less important ones
> > 
> >   + minimum_console_loglevel defines the minimum
> >     console_loglevel that might be set by userspace
> >     via syslog interface; it prevents userspace from
> >     hiding emergency messages
> > 
> >   + ignore_loglevel allows to see all messages
> >     easily; it is used for debugging
> > 
> > IMPORTANT: console_level is increased in some special
> > situations to see everything, e.g. in panic(), oops_begin(),
> > __handle_sysrq().
> > 
> > I guess that people want to see all messages even on the slow
> > console during panic(), oops(), with ignore_loglevel. It means
> > that the new per-console setting must not limit it. Also any
> > console must not go below minimum_console_level.
> 
> I can definitely take oops_in_progress and minimum_console_level into
> account in the drop condition. I can also send a patch to make the sysrq
> handler reset all the maxlevels to LOGLEVEL_DEBUG if you like.

Please note that you must not call console_lock() in the sysrq
handler. The function might sleep and it is irq context.
By other words, you could not manipulate the console structures
there.


> > What about doing it the other way and define min_loglevel
> > for each console. It might be used to make selected consoles
> > always more verbose (above current console_level) but it
> > will not limit the more verbose modes.
> 
> I think it's more intuitive to let the global sysctl behave as it always
> has, and allow additional filtering of higher levels downstream. I can
> definitely see why users might find this a bit confusing, but IMHO
> stacking two "filters" is more intuitive than a "filter" and a "bypass".

I do not have strong opinion here. I like the idea of this patch.
Sadly, the console setting already is pretty confusing.

I know that many people, including me, have troubles to understand
the meaning of the 4 numbers in /proc/sys/kernel/printk. They set

	console_loglevel
	default_message_loglevel
	minimum_console_loglevel
	default_console_loglevel

And we are going to add another complexity :-(


> How about a read-only "functional_loglevel" attribute for each console
> that displays:
> 
> 	max(min(console_level, con->maxlevel), minimum_console_level)

I like this idea and it inspired me. What about creating the following
structure under /sys

  /sys/consoles/<name1>/loglevel
		       /minimum_loglevel
	       /<name2>/loglevel
		       /minimum_loglevel
	       /loglevel
	       /minimum_loglevel

The semantic would be:

   + global loglevel will show the current default console_loglevel,
     it must be above the global minimum_console_loglevel

   + the per-console loglevel will show the loglevel specific
     for the given console; it must be above the per-console
     minimum_loglevel while

   + the per-console minimum_loglevel must be above the global
     minimum_console_loglevel

   The setting of the global values would affect the per-console
   values but it must respect the above rules.

   It is still the "filter" and "bypass" logic. But we will just
   repeat the existing terms and logic. Also note that
   "ignore_loglevel" and the special modes in sysrq, panic, oops
   use the "bypass" logic as well.


> Would that make the semantics more obvious? I'll obviously also send
> patches for Documentation once there's consensus about the interface.

Please add also linux-api@...r.kernel.org, especially for the
patch adding the new toplevel directory under /sys.

Best Regards,
Petr