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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170406225250.tz7ltv7s4d4xjrxy@Haydn>
Date:   Thu, 6 Apr 2017 15:52:50 -0700
From:   Calvin Owens <calvinowens@...com>
To:     Petr Mladek <pmladek@...e.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 Thursday 04/06 at 16:02 +0200, Petr Mladek wrote:
> 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.

Sure, I'd punt it to process context somehow.
 
> > > 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.

Okay, I see where you're coming from. Let me play with this a bit, I'll
send something concrete in the next day or two.

> > 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.

Will do.

Thanks,
Calvin

> Best Regards,
> Petr