Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755400AbcDDMq7 (ORCPT ); Mon, 4 Apr 2016 08:46:59 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:59773 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755018AbcDDMq6 (ORCPT ); Mon, 4 Apr 2016 08:46:58 -0400 Date: Mon, 4 Apr 2016 14:46:34 +0200 From: Peter Zijlstra To: Jan Kara Cc: Andy Lutomirski , Borislav Petkov , Andy Lutomirski , X86 ML , Paolo Bonzini , KVM list , Arjan van de Ven , xen-devel , "linux-kernel@vger.kernel.org" , Linus Torvalds , Andrew Morton , pmladek@suse.cz Subject: Re: [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception Message-ID: <20160404124634.GS3430@twins.programming.kicks-ass.net> References: <4085070316fc3ab29538d3fcfe282648d1d4ee2e.1459605520.git.luto@kernel.org> <20160402183919.GA2538@pd.tnic> <20160402204752.GC2538@pd.tnic> <20160404115206.GG8372@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160404115206.GG8372@quack.suse.cz> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1893 Lines: 64 On Mon, Apr 04, 2016 at 01:52:06PM +0200, Jan Kara wrote: > Sounds like a good idea to me. I've also consulted this with Petr Mladek > (added to CC) who is using printk_func per-cpu variable in his > printk-from-NMI patches and he also doesn't see a problem with this. There's a few printk() variants that do not go through this; which means they're broken for a number of cases, including the kdb printk redirection, this NMI stuff etc. > I was just wondering about one thing - this way we add more early printks > if I understand your intention right. Are we guaranteed that they happen > only from a single CPU? Because currently there is no locking in > early_printk() and thus we can end up writing to early console several > messages in parallel from different CPUs. Not sure what's going to happen > in that case... You get lovely per char interleaving on you serial line ;-) What I've done in the past was something like the below; that way you only get the normal task->softirq->irq->nmi nesting, which is mostly decipherable. diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index bfbf284e4218..c4c3269ff104 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -1907,17 +1907,36 @@ struct console *early_console; asmlinkage __visible void early_printk(const char *fmt, ...) { va_list ap; + static int print_cpu = -1; char buf[512]; - int n; + int n, cpu; if (!early_console) return; + preempt_disable(); + cpu = raw_smp_processor_id(); + for (;;) { + if (READ_ONCE(print_cpu) == cpu) + break; + + if (READ_ONCE(print_cpu) == -1 && + cmpxchg(&print_cpu, -1, cpu) == -1) { + cpu = -1; + break; + } + + cpu_relax(); + } + va_start(ap, fmt); n = vscnprintf(buf, sizeof(buf), fmt, ap); va_end(ap); early_console->write(early_console, buf, n); + + smp_store_release(&print_cpu, cpu); + preempt_enable(); } #endif