Subject: Re: x86/pti: smp_processor_id() called while preemptible in
 resume-from-sleep
To: Linus Torvalds <torvalds@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>
References: <20171230132927.GA2731@light.dominikbrodowski.net>
 <alpine.DEB.2.20.1712301558500.1899@nanos>
 <20171230153054.GA1604@light.dominikbrodowski.net>
 <alpine.DEB.2.20.1712301916020.1899@nanos>
 <CA+55aFybDbanqpA2eSy1oSCUj9a8RPuAgQYEZN8c+Rfege1a3Q@mail.gmail.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>,
        Andy Lutomirski <luto@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
        the arch/x86 maintainers <x86@kernel.org>
From: Dave Hansen <dave.hansen@linux.intel.com>
Message-ID: <dbbfefd1-43d8-07af-dea7-c453650ab1d5@linux.intel.com>
Date: Sat, 30 Dec 2017 11:03:30 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <CA+55aFybDbanqpA2eSy1oSCUj9a8RPuAgQYEZN8c+Rfege1a3Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 809
Lines: 21

On 12/30/2017 10:40 AM, Linus Torvalds wrote:
> The __native_flush_tlb() function looks _very_ broken.
...
> So I'd suggest moving the preempt_disable() up to the top of that
> function, regardless of whether we could then remove that seemingly
> stale TLB flush in that crazy
> smpboot_setup/restore_warm_reset_vector() dance...

If someone is calling __native_flush_tlb(), shouldn't they already be in
a state where they can't be preempted?  It's fundamentally a one-cpu
thing, both the actual CPU TLB flush _and_ the per-cpu variables.

It seems like we might want to _remove_ the explicit
preempt_dis/enable() from here:

        preempt_disable();
        native_write_cr3(__native_read_cr3());
        preempt_enable();

and add some warnings to ensure it's disabled when we enter
__native_flush_tlb().