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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ