From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754349AbcCWJZq (ORCPT ); Wed, 23 Mar 2016 05:25:46 -0400 Received: from mx2.suse.de ([195.135.220.15]:47252 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753964AbcCWJZp (ORCPT ); Wed, 23 Mar 2016 05:25:45 -0400 Date: Wed, 23 Mar 2016 10:25:41 +0100 From: Petr Mladek To: Sergey Senozhatsky Cc: 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: <20160323092541.GC5522@pathway.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160323012238.GB641@swordfish> 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 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. > - second, smp_send_stop() does not guarantee that all of the CPUs received > STOP IPI by the time it returns. on some platforms (ARM, for instance) > smp_send_stop() Good to know. > so I wanted to have in printk some panic indication that once set never > gets cleared. my proposal was > > void console_panic(void) > { > printk_sync = false; > } Great idea. I think that we want to call this in panic() instead of in vprintk_emit(). I mean that we should change the global flag only when we are really going down. Best Regards, Petr