From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752294AbbGIOKz (ORCPT ); Thu, 9 Jul 2015 10:10:55 -0400 Received: from cantor2.suse.de ([195.135.220.15]:53093 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751146AbbGIOKs (ORCPT ); Thu, 9 Jul 2015 10:10:48 -0400 Date: Thu, 9 Jul 2015 16:10:42 +0200 From: Jan Kara To: "Luis R. Rodriguez" Cc: Gavin Hu , Petr Mladek , linux-kernel@vger.kernel.org, Alex Elder , "Steven Rostedt (Red Hat)" , Joe Perches , 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: <20150709141042.GH2900@quack.suse.cz> References: <20150708081334.GJ32664@pathway.suse.cz> <20150708170402.GZ7021@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150708170402.GZ7021@wotan.suse.de> 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 08-07-15 19:04:02, 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 ? Well, there are patches which try to fix this problem. Petr has referenced them (at least one posting of them) and we do carry them in SLES kernels (since without them some big machines aren't able to boot with serial console attached). The biggest obstacle for them to get merged was that: a) Andrew Morton didn't like the additional complexity in the printk code. b) Alan Cox was objecting that the problem isn't in the printk code but rather in serial console drivers which are too slow to print and thus we should instead implement some buffering there. If people care, I can refresh my memory where we ended, refresh the patches and repost them. Probably we should deal with this one way or another... > 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. I don't think keying on message type is a good idea. You want to keep message ordering in the first place so KERN_EMERG message would have to print everything before it in the printk ring buffer but with other levels being async this may take even longer than before... So I don't think we should do that unless really necessary. Printk code currently keys on 'oops_in_progress' to do some special hacks making messages more likely to appear on console and my patches use the same to switch to a sync mode where we write out everything we have regardless of how long it takes (at that point we are doomed anyway so some additional softlockup won't make matters much worse). Honza -- Jan Kara SUSE Labs, CR