From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752105AbbE0XNx (ORCPT ); Wed, 27 May 2015 19:13:53 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:58618 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751055AbbE0XNs (ORCPT ); Wed, 27 May 2015 19:13:48 -0400 Date: Wed, 27 May 2015 16:13:46 -0700 From: Andrew Morton To: Petr Mladek Cc: Frederic Weisbecker , Steven Rostedt , Dave Anderson , "Paul E. McKenney" , Kay Sievers , Jiri Kosina , Michal Hocko , Jan Kara , linux-kernel@vger.kernel.org, Wang Long , peifeiyue@huawei.com, dzickus@redhat.com, morgan.wang@huawei.com, sasha.levin@oracle.com Subject: Re: [PATCH 01/10] printk: Avoid deadlock in NMI context Message-Id: <20150527161346.fb3178d393ebbaafea4e3906@linux-foundation.org> In-Reply-To: <1432557993-20458-2-git-send-email-pmladek@suse.cz> References: <1432557993-20458-1-git-send-email-pmladek@suse.cz> <1432557993-20458-2-git-send-email-pmladek@suse.cz> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 25 May 2015 14:46:24 +0200 Petr Mladek 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/