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: <20170405020800.GB11669@jagdpanzerIV.localdomain>
Date:   Wed, 5 Apr 2017 11:08:00 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Calvin Owens <calvinowens@...com>
Cc:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...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
Subject: Re: [RFC][PATCH 1/2] printk: Introduce per-console filtering of
 messages by loglevel

On (04/04/17 16:02), Calvin Owens wrote:
[..]
>  static void call_console_drivers(const char *ext_text, size_t ext_len,
> -				 const char *text, size_t len)
> +				 const char *text, size_t len, int level)
>  {
>  	struct console *con;
>  
> @@ -1581,6 +1581,8 @@ static void call_console_drivers(const char *ext_text, size_t ext_len,
>  		if (!cpu_online(smp_processor_id()) &&
>  		    !(con->flags & CON_ANYTIME))
>  			continue;
> +		if (level > con->maxlevel)
> +			continue;
>  		if (con->flags & CON_EXTENDED)
>  			con->write(con, ext_text, ext_len);
>  		else
> @@ -1869,7 +1871,7 @@ static ssize_t msg_print_ext_body(char *buf, size_t size,
>  				  char *dict, size_t dict_len,
>  				  char *text, size_t text_len) { return 0; }
>  static void call_console_drivers(const char *ext_text, size_t ext_len,
> -				 const char *text, size_t len) {}
> +				 const char *text, size_t len, int level) {}
>  static size_t msg_print_text(const struct printk_log *msg,
>  			     bool syslog, char *buf, size_t size) { return 0; }
>  static bool suppress_message_printing(int level) { return false; }
> @@ -2238,7 +2240,7 @@ void console_unlock(void)
>  		raw_spin_unlock(&logbuf_lock);
>  
>  		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?

	-ss

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ