linux-kernel - sysrq 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-next>] [day] [month] [year] [list]

Date:	Wed, 7 Jan 2009 12:37:58 +0000
From:	Andy Whitcroft <apw@...onical.com>
To:	Crutcher Dunnavant <crutcher+kernel@...astacks.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: sysrq loglevel

It seems that we deliberatly manage the console_loglevel while handling a
sysrq request.  Raising it to 7 to emit the sysrq command header, and then
lower it before processing the command itself.  When booting the kernel
'quiet' this means that we only see the header of the command and not its
output on the console, the whole thing is in dmesg and thereby in syslog
(if it is working).

void __handle_sysrq(int key, struct tty_struct *tty, int check_mask)
[...]
        console_loglevel = 7;
        printk(KERN_INFO "SysRq : ");
[...]
                        printk("%s\n", op_p->action_msg);
                        console_loglevel = orig_log_level;
                        op_p->handler(key, tty);
[...]

Is this intentional?  I can see arguments both ways.  One way to look at
it would be that I asked for the output so I should get it regardless.
The other side might be that consoles can be really slow (serial or
something) and so only outputting it there if logging is enabled
generally is sane.

Obviously we can work round this at the moment using sysrq-7 to up the
loglevel before the command and sysrq-4 after to restore quiet.

What do people think.  If we are happy with the status quo then I will
spin a documentation patch to point out this behaviour and the work
around.  Else I will happily spin a patch to fix it.

Thoughts?

-apw
--
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/