From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758164AbdJMNaf (ORCPT ); Fri, 13 Oct 2017 09:30:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:37384 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753258AbdJMNae (ORCPT ); Fri, 13 Oct 2017 09:30:34 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1461321876 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Fri, 13 Oct 2017 09:30:31 -0400 From: Steven Rostedt To: Petr Mladek Cc: Peter Zijlstra , sergey.senozhatsky@gmail.com, linux-kernel@vger.kernel.org, mingo@kernel.org, tglx@linutronix.de Subject: Re: [PATCH 2/3] early_printk: Add force_early_printk kernel parameter Message-ID: <20171013093031.2734e207@gandalf.local.home> In-Reply-To: <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> <20171013130609.GC2795@pathway.suse.cz> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 13 Oct 2017 15:06:09 +0200 Petr Mladek wrote: > > > > 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. I think it makes sense to have force_early_printk depend on PRINTK and EARLY_PRINTK. > > 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"). Yes, I agree with Petr here. Slapping the force printk into printk_func() should have the same effect, as everything is hard coded now: asmlinkage __visible int printk(const char *fmt, ...) { va_list args; int r; va_start(args, fmt); r = vprintk_func(fmt, args); va_end(args); return r; } __printf(1, 0) int vprintk_func(const char *fmt, va_list args) { /* Use extra buffer in NMI when logbuf_lock is taken or in safe mode. */ if (this_cpu_read(printk_context) & PRINTK_NMI_CONTEXT_MASK) return vprintk_nmi(fmt, args); /* Use extra buffer to prevent a recursion deadlock in safe mode. */ if (this_cpu_read(printk_context) & PRINTK_SAFE_CONTEXT_MASK) return vprintk_safe(fmt, args); /* * Use the main logbuf when logbuf_lock is available in NMI. * But avoid calling console drivers that might have their own locks. */ if (this_cpu_read(printk_context) & PRINTK_NMI_DEFERRED_CONTEXT_MASK) return vprintk_deferred(fmt, args); /* No obstacles. */ return vprintk_default(fmt, args); } Thus putting in the call to early_printk() at the very beginning of vprintk_func() would have the result that Peter would like. -- Steve