Date: Wed, 5 Apr 2017 17:38:19 -0700
From: Calvin Owens <calvinowens@fb.com>
To: Petr Mladek <pmladek@suse.com>
CC: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Jiri Slaby" <jslaby@suse.cz>,
        Andrew Morton <akpm@linux-foundation.org>,
        Manuel =?utf-8?Q?Sch=C3=B6lling?= <manuel.schoelling@gmx.de>,
        Hans de Goede <hdegoede@redhat.com>,
        Paul Burton <paul.burton@imgtec.com>, <linux-kernel@vger.kernel.org>,
        <kernel-team@fb.com>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [RFC][PATCH 1/2] printk: Introduce per-console filtering of
 messages by loglevel
Message-ID: <20170406003819.dgbkdixvh6tn7hk5@Haydn>
References: <bc1fe800930be76761b2bb4e6108fe5876a005c9.1491345440.git.calvinowens@fb.com>
 <20170405020800.GB11669@jagdpanzerIV.localdomain>
 <20170405021628.GC11669@jagdpanzerIV.localdomain>
 <20170405152256.GS3452@pathway.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <20170405152256.GS3452@pathway.suse.cz>
User-Agent: NeoMutt/20170306 (1.8.0)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2017 00:38:25.4932 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1221
X-OriginatorOrg: fb.com
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-05_17:,,
 signatures=0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3687
Lines: 104

On Wednesday 04/05 at 17:22 +0200, Petr Mladek wrote:
> 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?

I think it makes sense as long as we're clear about the semantics: if a
message would normally be printed to the console according to the global
settings, this allows you to limit the loglevel a specific console will
print.

Petr suggested the opposite approach, I'll address that below.
 
> 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.

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

How about a read-only "functional_loglevel" attribute for each console
that displays:

	max(min(console_level, con->maxlevel), minimum_console_level)

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

Thanks,
Calvin

> Best Regards,
> Petr