From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755800AbcDDPcn (ORCPT ); Mon, 4 Apr 2016 11:32:43 -0400 Received: from mail-oi0-f43.google.com ([209.85.218.43]:33790 "EHLO mail-oi0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754562AbcDDPcm (ORCPT ); Mon, 4 Apr 2016 11:32:42 -0400 MIME-Version: 1.0 In-Reply-To: <20160404115206.GG8372@quack.suse.cz> References: <4085070316fc3ab29538d3fcfe282648d1d4ee2e.1459605520.git.luto@kernel.org> <20160402183919.GA2538@pd.tnic> <20160402204752.GC2538@pd.tnic> <20160404115206.GG8372@quack.suse.cz> From: Andy Lutomirski Date: Mon, 4 Apr 2016 08:32:21 -0700 Message-ID: Subject: Re: [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception To: Jan Kara Cc: Paolo Bonzini , xen-devel , Arjan van de Ven , Borislav Petkov , X86 ML , Andrew Morton , Petr Mladek , KVM list , "linux-kernel@vger.kernel.org" , Linus Torvalds , Peter Zijlstra Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Apr 4, 2016 4:51 AM, "Jan Kara" wrote: > > On Sat 02-04-16 13:58:19, Andy Lutomirski wrote: > > [cc Jan Kara] > > > > On Sat, Apr 2, 2016 at 1:47 PM, Borislav Petkov wrote: > > > On Sat, Apr 02, 2016 at 01:13:37PM -0700, Andy Lutomirski wrote: > > >> Given that I this isn't really a regression with my patches (it > > >> probably never worked much better on 32-bit and the regs never would > > >> have shown at all on 64-bit), > > > > > > You're right. That thing calls printk *and* early_printk, WTF: > > > > > > #ifdef CONFIG_EARLY_PRINTK > > > > > > call early_printk > > > ... > > > > > > call dump_stack > > > > > > ... > > > > > > call __print_symbol > > > > > > those last two call printk. Great. > > > > > >> I propose a different approach: make > > >> printk work earlier. Something like: > > >> > > >> if (early) { > > >> early_printk(args); > > >> } > > >> > > >> or early_vprintk or whatever. > > >> > > >> If the cost of a branch mattered, this could be alternative-patched > > >> out later on, but that seems silly. I also bet that a more sensible > > >> fallback could be created in which printk would try to use an early > > >> console if there's no real console. > > > > > > So how about this: > > > > > > printk() does > > > > > > vprintk_func = this_cpu_read(printk_func); > > > > > > and that's > > > > > > DEFINE_PER_CPU(printk_func_t, printk_func) = vprintk_default > > > > > > I guess we can make that function be early_printk-something and once > > > printk is initialized, we overwrite it with vprintk_default. > > > > > > Elegant and no need for if branches and alternatives. > > > > > > Hmmm. > > > > Jan, IIRC you were looking at printk recently-ish. Any thoughts here? > > 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. > > 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... Adding locking would be easy enough, wouldn't it? But do any platforms really boot a second CPU before switching to real printk? Given that I see all the smpboot stuff in dmesg, I guess real printk happens first. I admit I haven't actually checked. --Andy > > Honza > -- > Jan Kara > SUSE Labs, CR