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: <20170405152256.GS3452@pathway.suse.cz>
Date:   Wed, 5 Apr 2017 17:22:56 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Calvin Owens <calvinowens@...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 11:16:28, Sergey Senozhatsky wrote:
> On (04/05/17 11:08), Sergey Senozhatsky wrote:
> [..]
> > >  		stop_critical_timings();	/* don't trace print latency */
> > > -		call_console_drivers(ext_text, ext_len, text, len);
> > > +		call_console_drivers(ext_text, ext_len, text, len, msg->level);
> > >  		start_critical_timings();
> > >  		printk_safe_exit_irqrestore(flags);
> > 
> > ok, so the idea is quite clear and reasonable.
> > 
> > 
> > some thoughts,
> > we have a system-wide suppress_message_printing() loglevel filtering
> > in console_unlock() loop, which sets a limit on loglevel for all of
> > the messages - we don't even msg_print_text() if the message has
> > suppressible loglevel. and this implicitly restricts per-console
> > maxlevels.
> > 
> > console_unlock()
> > {
> > 	for (;;) {
> > 		...
> > skip:
> > 
> > 		if (suppress_message_printing(msg->level))	// console_loglevel
> > 			goto skip;
> > 
> > 		call_console_drivers(msg->level)
> > 			{
> > 				if (level > con->maxlevel)	// con loglevel
> > 					continue;
> > 				...
> > 			}
> > 	}
> > }
> > 
> > this can be slightly confusing. what do you think?
> 
> one more thing.
> 
> this per-console filtering ignores... the "ignore_loglevel" param.
> 
> early_param("ignore_loglevel", ignore_loglevel_setup);
> module_param(ignore_loglevel, bool, S_IRUGO | S_IWUSR);
> MODULE_PARM_DESC(ignore_loglevel,
> 		 "ignore loglevel setting (prints all kernel messages to the console)");
> 
> 
> my preference would be preserve "ignore_loglevel" behaviour. if
> we are forced to 'ignore all loglevel filtering' then we should
> do so.

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.

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.

Best Regards,
Petr