From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751300AbbGIH5B (ORCPT ); Thu, 9 Jul 2015 03:57:01 -0400 Received: from cantor2.suse.de ([195.135.220.15]:53714 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750760AbbGIH4x (ORCPT ); Thu, 9 Jul 2015 03:56:53 -0400 Date: Thu, 9 Jul 2015 09:56:50 +0200 From: Petr Mladek To: Steven Rostedt Cc: Joe Perches , "Luis R. Rodriguez" , Gavin Hu , linux-kernel@vger.kernel.org, Alex Elder , Peter Hurley , Tejun Heo , cxie4@marvell.com, cldu@marvell.com, xjian@marvell.com, fswu@marvell.com, Jan Kara Subject: Re: printk: preempt_disable with long time resulting in softlockup/RCU stall issues Message-ID: <20150709075650.GA2673@pathway.suse.cz> References: <20150708081334.GJ32664@pathway.suse.cz> <20150708170402.GZ7021@wotan.suse.de> <1436376929.2682.85.camel@perches.com> <20150708140017.6c96d4d5@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150708140017.6c96d4d5@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 2015-07-08 14:00:17, Steven Rostedt wrote: > On Wed, 08 Jul 2015 10:35:29 -0700 > Joe Perches wrote: > > > On Wed, 2015-07-08 at 19:04 +0200, Luis R. Rodriguez wrote: > > > On Wed, Jul 08, 2015 at 05:08:35PM +0800, Gavin Hu wrote: > > > > Hi, > > > > > > > > Yes. We should disable the printk_limit feature when panic to avoid missing > > > > messages. > > > > > > Sounds like you have been looking into it and have a good idea of what you > > > want to do, why not try it and send some RFC patches ? > > > > > > While at it, then we could consider doing different things depending on the > > > message type. KERN_EMERG would disable preemption, whereas KERN_INFO may not be > > > so critical to require it. > > > > That might be a bit difficult to implement with complete correctness > > given KERN_EMERG use and continuation lines. > > > > Or just have the current context determine what to do. If printk() was > called with preemption or interrupts disabled, it flushes the full > buffer before returning, otherwise it allows the writes to console be > preempted. I am afraid that any variant of this approach will make the original problem even worse. There will be more messages waiting and it will increase the chance of the softlockup. I guess that people call printk() with disabled interrupts or preemption with the naive hope that it will be fast (just store the message in the ring buffer and come back). I think that we really need to break the console output when it takes too long and schedule it somewhere else. Best Regards, Petr