linux-kernel - Re: [PATCH,RFC,resend] printk: restore previous console

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: <20090710140749.GD26264@elte.hu>
Date:	Fri, 10 Jul 2009 16:07:49 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Frans Pop <elendil@...net.nl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Robin Getz <rgetz@...ckfin.uclinux.org>
Cc:	linux-kernel@...r.kernel.org, cryptsetup@...kages.debian.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH,RFC,resend] printk: restore previous console_loglevel
	when re-enabling logging


* Frans Pop <elendil@...net.nl> wrote:

> When logging to console is disabled from userspace using klogctl()
> and later re-enabled, console_loglevel gets set to the default
> log level instead to the previous value.
> This means that if the kernel was booted with 'quiet', the boot is
> suddenly no longer quiet after logging to console gets re-enabled.
> 
> Save the current console_loglevel when logging is disabled and
> restore to that value. If the log level is set to a specific value
> while disabled, this is interpreted as an implicit re-enabling of
> the logging.
> 
> Signed-off-by: Frans Pop <elendil@...net.nl>
> ---
> 
> Resend. The problem that prompted this patch is described in
> http://lkml.org/lkml/2009/6/28/234
> 
> There are two variations possible on the patch below.
> 
> 1) If klogctl(7) is called while logging is not disabled, then set level
>    to default (partially preserving current functionality):
>  	case 7:		/* Enable logging to console */
> -		console_loglevel = default_console_loglevel;
> +		if (saved_console_loglevel == -1)
> +			console_loglevel = default_console_loglevel;
> +		else {
> +			console_loglevel = saved_console_loglevel;
> +			saved_console_loglevel = -1;
> +		}
> 
> 2) If klogctl(8) is called while logging is disabled, then don't enable
>    logging, but remember the requested value for when logging does get
>    enabled again:
>  	case 8:		/* Set level of messages printed to console */
> [...]
> - 		console_loglevel = len;
> +		if (saved_console_loglevel == -1)
> +	 		console_loglevel = len;
> +		else
> +			saved_console_loglevel = len;
> 
> Yet another option would be to ignore the request.

Looks like a possible solution to a real problem (most distros today 
boot with quiet) - albeit it does change previous behavior so 
objections are possible on those grounds.

I've queued it up in the tip:core/printk tree and will push it out 
to linux-next in a few days if there are no objections.

Small sidenote: i moved the (somewhat obscurely placed) 
saved_console_loglevel static variable out of local variable scope 
and next to the console loglevel definitions (such as 
console_printk[]), to increase its visibility as globally relevant 
state and to move it next to the state this variable affects.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/