From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751814AbdJPLIw (ORCPT <rfc822;w@1wt.eu>);
        Mon, 16 Oct 2017 07:08:52 -0400
Received: from mail-pf0-f195.google.com ([209.85.192.195]:52319 "EHLO
        mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750829AbdJPLIu (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 16 Oct 2017 07:08:50 -0400
X-Google-Smtp-Source: AOwi7QB+t8bEDsqCP4SSeCOxt7C8n3OLB9Hifc4bWKwu4ba2eI3SfY7k8nqV9uYLIYfP6rU6T5z8HA==
Date: Mon, 16 Oct 2017 20:08:45 +0900
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] printk: Remove superfluous memory barriers from
 printk_safe
Message-ID: <20171016110845.GB6316@tigerII.localdomain>
References: <20171011124647.7781f98f@gandalf.local.home>
 <20171014092129.GD2973@tigerII.localdomain>
 <20171015202715.5c3bb075@vmware.local.home>
 <20171016081252.GG2795@pathway.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171016081252.GG2795@pathway.suse.cz>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On (10/16/17 10:12), Petr Mladek wrote:
[..]
> > > it's not only NMI related, printk() recursion can happen at any stages,
> > > including... um... wait a second. ... including the "before we set up
> > > per-CPU areas" stage? hmm... smells like a bug?
> > 
> > I think this was just being overly paranoid.
> 
> I was curious because it was not only about reading the per-CPU
> variables. We set and clear the printk_context per-CPU variable
> in every printk() call. I wondered if we accessed some
> non-initialized stuff.
> 
> Fortunately, it seems that we are on the safe side.
> 
> If I get it correctly, the per-CPU variables are set up in
> setup_per_cpu_areas(). But some per-CPU variables are used even
> before, see
> 
>   boot_cpu_init()
>     smp_processor_id()
>       raw_smp_processor_id()
> 	this_cpu_read(cpu_number)
> 
> IMHO, the trick is the following code in setup_per_cpu_areas()
> from arch/x86/kernel/setup_percpu.c:
> 
> 		/*
> 		 * Up to this point, the boot CPU has been using .init.data
> 		 * area.  Reload any changed state for the boot CPU.
> 		 */
> 		if (!cpu)
> 			switch_to_new_gdt(cpu);
> 
> IMHO, this means that per-CPU variable for the first boot-CPU
> can be used at any time. And all the interesting functions:
> boot_cpu_init(), setup_per_cpu_areas(), printk_safe_init() are
> still called in the single-CPU mode.

hm... not so sure, need to check more.

we can access DECLARE_EARLY_PER_CPU() things, which we must copy after
per-cpu pages are set up. `cpu_number' is DECLARE_EARLY_PER_CPU(), btw.

	-ss