Messages in this thread | | | Date | Wed, 27 May 2015 16:13:46 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 01/10] printk: Avoid deadlock in NMI context |
| |
On Mon, 25 May 2015 14:46:24 +0200 Petr Mladek <pmladek@suse.cz> wrote:
> printk() cannot be used in NMI context safely because it uses an internal > lock and thus could cause a deadlock. This is fine because NMI context > is very special. The handlers should be short, effective, and do not > use printk(). > > But developers tend to print warnings even from NMI code. They are pretty > hard to debug when they lockup the machine and nothing appears in the logs. > > This patch prevents from the deadlock on logbuf_lock by using trylock > rather than spin_lock. If the lock can not be taken, the message is > ignored and some warning is printed later on. > > We also must not try to get console from NMI context. It needs > even more locks and there is even higher chance to hung up. > > Unfortunately, we could not print more details about the lost message. > We could not alloc a buffer in NMI. Therefore we would need some > lockless mechanism to share a buffer between NMI and normal context. > But this would make printk() code much more complicated and > it is not worth it. There has already been an attempt to do so > and it has been rejected, see https://lkml.org/lkml/2014/6/10/388 > This is also the reason why we use the atomic counter.
hm, I expect it wouldn't be too messy to shove the text into a static per-cpu buffer. So we at least get a few hundred bytes of stuff.
Or maybe just save the address of the control string perhaps, so the message later comes out without any of its %thingies filled in. That's racy against rmmod and requires that the control string be in static storage (which is basically always true). Of course, it might just be "%s" ;). Forget I suggested this.
> + /* emit KERN_CRIT message */ > + printed_len += log_store(0, 2, LOG_PREFIX|LOG_NEWLINE, 0, + NULL, 0, text, text_len);
s/2/LOGLEVEL_CRIT/
| |