On 12/30/2017 07:30 AM, Dominik Brodowski wrote:
>
> native_cpu_up+0x447/0xa30:
> kern_pcid at arch/x86/include/asm/tlbflush.h:105
> (inlined by) invalidate_user_asid at arch/x86/include/asm/tlbflush.h:342
> (inlined by) __native_flush_tlb at arch/x86/include/asm/tlbflush.h:351
> (inlined by) smpboot_restore_warm_reset_vector at
> arch/x86/kernel/smpboot.c:146
> (inlined by) do_boot_cpu at arch/x86/kernel/smpboot.c:1022
> (inlined by) native_cpu_up at arch/x86/kernel/smpboot.c:1070
This appears to be this path:
> static inline void smpboot_restore_warm_reset_vector(void)
> {
> unsigned long flags;
>
> /*
> * Install writable page 0 entry to set BIOS data area.
> */
> local_flush_tlb();
The PTI code is now tracking when a given ASID needs to get flushed in a
per-cpu variable, and we use smp_processor_id() in local_flush_tlb() to
do that tracking. That's the *proximate* cause of the new warning. I
think it's actually a quite valid warning that's catching something
questionable.
I'm limited here by not knowing how the warm reset vector actually
works, though. I don't know why we TLB flush at all, much less why we
do it after CMOS_WRITE() in the "setup" path but _before_ CMOS_WRITE()
in the "restore" one. Where do we actually "Install writable page 0
entry to set BIOS data area"? Shouldn't we just be flushing _there_?
But, even _doing_ a TLB flush with preempt enabled and interrupts on
seems wrong to me. It just fundamentally doesn't mean anything because
it can theoretically run anywhere and flush *any* TLB. There might be
some other implicit preempt-thwarting going on here, but I can't find it.
The naive fix here is to just preempt_dis/enable() over the area doing
the flush and the writes to the TRAMPOLINE_* area. That'll definitely
shut up the warnings.
