From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758070AbdJMNGN (ORCPT ); Fri, 13 Oct 2017 09:06:13 -0400 Received: from mx2.suse.de ([195.135.220.15]:51474 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753380AbdJMNGM (ORCPT ); Fri, 13 Oct 2017 09:06:12 -0400 Date: Fri, 13 Oct 2017 15:06:09 +0200 From: Petr Mladek To: Peter Zijlstra Cc: sergey.senozhatsky@gmail.com, linux-kernel@vger.kernel.org, rostedt@goodmis.org, mingo@kernel.org, tglx@linutronix.de Subject: Re: [PATCH 2/3] early_printk: Add force_early_printk kernel parameter Message-ID: <20171013130609.GC2795@pathway.suse.cz> References: <20170928121823.430053219@infradead.org> <20170928122513.376168124@infradead.org> <20171012102419.GE2882@pathway.suse.cz> <20171012113949.kb7xhrk6u27fqdc7@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171012113949.kb7xhrk6u27fqdc7@hirez.programming.kicks-ass.net> 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 Thu 2017-10-12 13:39:49, Peter Zijlstra wrote: > On Thu, Oct 12, 2017 at 12:24:19PM +0200, Petr Mladek wrote: > > On Thu 2017-09-28 14:18:25, Peter Zijlstra wrote: > > > > +#ifdef CONFIG_EARLY_PRINTK > > > +struct console *early_console; > > > + > > > +static bool __read_mostly force_early_printk; > > > + > > > +static int __init force_early_printk_setup(char *str) > > > +{ > > > + force_early_printk = true; > > > + return 0; > > > +} > > > +early_param("force_early_printk", force_early_printk_setup); > > > > The parameter is currently used only when CONFIG_PRINTK is enabled. > > But CONFIG_EARLY_PRINTK is independent. What would be your preferred > > behavior when CONFIG_PRINTK is disabled, please? > > Can we even have !PRINTK && EARLY_PRINTK? If so it seems to me continued > usage of early_printk() is what makes most sense. Yes, !PRINTK && EARLY_PRINTK is possible at the moment. It makes some sense because EARLY_PRINTK needs only consoles and they are needed also for !PRINTK stuff. We either should define force_early_printk only when PRINTK is enabled. Or we should call early_printk() from printk() also when PRINTK is disabled. The current implemetation is in include/linux/printk.h, see static inline __printf(1, 2) __cold int printk(const char *s, ...) { return 0; } > > > @@ -1816,6 +1852,11 @@ asmlinkage int vprintk_emit(int facility > > > return vkdb_printf(KDB_MSGSRC_PRINTK, fmt, args); > > > #endif > > > > > > +#ifdef CONFIG_EARLY_PRINTK > > > + if (force_early_printk && early_console) > > > + return early_vprintk(fmt, args); > > > +#endif > > > + > > > if (level == LOGLEVEL_SCHED) { > > > level = LOGLEVEL_DEFAULT; > > > in_sched = true; > > > @@ -1939,7 +1980,12 @@ asmlinkage __visible int printk(const ch > > > int r; > > > > > > va_start(args, fmt); > > > - r = vprintk_func(fmt, args); > > > +#ifdef CONFIG_EARLY_PRINTK > > > + if (force_early_printk && early_console) > > > + r = vprintk_default(fmt, args); > > > + else > > > +#endif > > > + r = vprintk_func(fmt, args); > > > > There is rather theoretical race. We skip vprintk_func() because > > we believe that vprintk_default()/vprintk_emit() would choose > > handle this by early_printk(). > > Do you mean if someone were to toggle force_early_printk at runtime? Or that someone unregisters the early console. > The reason I did it like this and not use that function pointer thing is > that I didn't want to risk anybody hijacking my output ever. I understand. I think about refactoring the code so that all *printk*() variants call printk_func(). This function could then call the right printk implementation according to the context or global setting. This way we could have all the logic on a single place and avoid the race. Note that printk_func() is not longer a pointer. It is a function since the commit 099f1c84c0052ec1b2 ("printk: introduce per-cpu safe_print seq buffer"). Best Regards, Petr