Messages in this thread | | | Date | Mon, 16 Oct 2017 20:08:45 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH] printk: Remove superfluous memory barriers from printk_safe |
| |
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
| |