Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751148AbdL3TPE (ORCPT ); Sat, 30 Dec 2017 14:15:04 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:34138 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750997AbdL3TPD (ORCPT ); Sat, 30 Dec 2017 14:15:03 -0500 X-Google-Smtp-Source: ACJfBou+XHkrXJhXCRK8k0WXRA+oF3VqEUnr33vDxW5dVL5Zog9TOVTeJhypuk6dynUr44/mjfcgFDQGi71qxg8PbzM= MIME-Version: 1.0 In-Reply-To: References: <20171230132927.GA2731@light.dominikbrodowski.net> <20171230153054.GA1604@light.dominikbrodowski.net> From: Linus Torvalds Date: Sat, 30 Dec 2017 11:15:02 -0800 X-Google-Sender-Auth: 1OexY6t5gNle1QOrzCHV-viwv8s Message-ID: Subject: Re: x86/pti: smp_processor_id() called while preemptible in resume-from-sleep To: Dave Hansen Cc: Thomas Gleixner , Dominik Brodowski , Andy Lutomirski , LKML , "the arch/x86 maintainers" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1155 Lines: 32 On Sat, Dec 30, 2017 at 11:03 AM, Dave Hansen wrote: > 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. Hmm. I think you're right. > 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(). Agreed, that would certainly also be consistent. The current code that disables preemption only selectively seems insane to me. Either all or nothing, not this crazy half-way thing. Linus