From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755415AbcCWNTx (ORCPT ); Wed, 23 Mar 2016 09:19:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:48897 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753448AbcCWNTo (ORCPT ); Wed, 23 Mar 2016 09:19:44 -0400 Date: Wed, 23 Mar 2016 14:20:11 +0100 From: Jan Kara To: Petr Mladek Cc: Sergey Senozhatsky , Sergey Senozhatsky , Andrew Morton , Jan Kara , Tejun Heo , Tetsuo Handa , linux-kernel@vger.kernel.org, Byungchul Park , Jan Kara Subject: Re: [RFC][PATCH v6 1/2] printk: Make printk() completely async Message-ID: <20160323132011.GG4512@quack.suse.cz> References: <1458581130-8677-1-git-send-email-sergey.senozhatsky@gmail.com> <1458581130-8677-2-git-send-email-sergey.senozhatsky@gmail.com> <20160322163612.GB5522@pathway.suse.cz> <20160323012238.GB641@swordfish> <20160323092541.GC5522@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160323092541.GC5522@pathway.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 23-03-16 10:25:41, Petr Mladek wrote: > On Wed 2016-03-23 10:24:43, Sergey Senozhatsky wrote: > > On (03/22/16 17:36), Petr Mladek wrote: > > > > - /* cpu currently holding logbuf_lock in this function */ > > > > - static unsigned int logbuf_cpu = UINT_MAX; > > > > + bool in_panic = console_loglevel == CONSOLE_LOGLEVEL_MOTORMOUTH; > > > > > > I am just looking at the printk in NMI patchset and I will need to > > > deal with the panic state as well. I am not sure if this detection > > > is secure. > > > > > > This console level is set also by kdb_show_stack() > > > and kdb_dumpregs(). I am not sure how this kdb stuff works > > > and if it affects normal kernel but... > > > > > > Anyway, it seems that many locations detects the panic situation > > > via the variable oops_in_progress. It has another advantage > > > that it can be easily checked and we would not need any extra > > > variable here. > > > > oops_in_progress is not my favorite global. and we can't rely on it > > in async printk. > > > > in panic() we have > > > > console_verbose(); > > bust_spinlocks(1); << sets to one > > > > pr_emerg("Kernel panic - not syncing: %s\n", buf); > > smp_send_stop(); > > > > bust_spinlocks(0); << sets it back to zero > > > > console_flush_on_panic(); > > > > there are several issues here. > > - first, panic_cpu does not see oops_in_progress right after bust_spinlocks(0). > > thus all printk issued from panic_cpu can go via async printk. > > I though that it actually could be an advantage. console_verbore() is > called also by oops_begin() and it does not need to be fatal. But you > are right that it does not need to be the righ approach. If we oops, I want printk to be sync regardless whether the machine is able to live afterwards or not. You never know in advance... That's why I've chosen the console_verbose() trigger and I still think it is better than oops_in_progress or special console_panic() trigger. Honza -- Jan Kara SUSE Labs, CR