Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755607AbdDEPYs (ORCPT ); Wed, 5 Apr 2017 11:24:48 -0400 Received: from mx2.suse.de ([195.135.220.15]:53428 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932679AbdDEPXE (ORCPT ); Wed, 5 Apr 2017 11:23:04 -0400 Date: Wed, 5 Apr 2017 17:22:56 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: Calvin Owens , Steven Rostedt , Greg Kroah-Hartman , Jiri Slaby , Andrew Morton , Manuel =?iso-8859-1?Q?Sch=F6lling?= , Hans de Goede , Paul Burton , linux-kernel@vger.kernel.org, kernel-team@fb.com, Sergey Senozhatsky Subject: Re: [RFC][PATCH 1/2] printk: Introduce per-console filtering of messages by loglevel Message-ID: <20170405152256.GS3452@pathway.suse.cz> References: <20170405020800.GB11669@jagdpanzerIV.localdomain> <20170405021628.GC11669@jagdpanzerIV.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170405021628.GC11669@jagdpanzerIV.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2869 Lines: 90 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