linux-kernel - Re: [PATCH RT] kernel/printk: Don't try to print from IRQ/NMI region

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] [day] [month] [year] [list]

Message-ID: <20160527161354.GD24120@linutronix.de>
Date:	Fri, 27 May 2016 18:13:54 +0200
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org,
	tglx@...utronix.de
Subject: Re: [PATCH RT] kernel/printk: Don't try to print from IRQ/NMI region

* Steven Rostedt | 2016-05-27 11:06:58 [-0400]:

>You probably didn't remove it. It may have been removed a while ago
>when Thomas did his big rewrite to get things working again.

okay. As long as I don't lose patches :)

>> about adding such a flag… I remember you had something in your tree to
>> print from IRQ off regions via UART.
>
>I had a few hacks for a while, but they were nothing more than hacks.
>
>Perhaps we should make a better early_printk() or simple console for RT
>that can handle printk in atomic locations.
>
>I have a hack patch that gives early_printk() a new "spin lock", where
>it only takes the lock if the owner isn't on the CPU. Otherwise it
>allows lock to continue (and wont release it). That hack was required
>to get legible output from early_printk() when I was getting a bunch of
>crashes on all the CPUs, because early_printk() has no locks, and the
>console is just a mess when all CPUs print at once.

An "atomic" console would be nice debugging wise. pstore with rawlocks
would be available after a reboot if you can use pstore. And its
overhead is probably not that huge. But its availability is limited.

Another thing might be a dedicated 8250 UART console which would print
in IRQ-off regions (and increase latency) but you would have the output
which you wouldn't have otherwise (say from panic() handler). Anyway,
nothing for production.

Sebastian