Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 5 Nov 2018 14:30:41 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     Nadav Amit <namit@vmware.com>
Cc:     Ingo Molnar <mingo@redhat.com>, linux-kernel@vger.kernel.org,
        x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Kees Cook <keescook@chromium.org>,
        Dave Hansen <dave.hansen@intel.com>,
        Masami Hiramatsu <mhiramat@kernel.org>
Subject: Re: [PATCH v3 6/7] x86/alternatives: use temporary mm for text poking
Message-ID: <20181105133041.GC22467@hirez.programming.kicks-ass.net>
References: <20181102232946.98461-1-namit@vmware.com>
 <20181102232946.98461-7-namit@vmware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181102232946.98461-7-namit@vmware.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Nov 02, 2018 at 04:29:45PM -0700, Nadav Amit wrote:
> +	unuse_temporary_mm(prev);
> +
> +	pte_unmap_unlock(ptep, ptl);

That; that does kunmap_atomic() on 32bit.

I've been thinking that the whole kmap_atomic thing on x86_32 is
terminally broken, and with that most of x86_32 is.

kmap_atomic does the per-cpu fixmap pte fun-and-games we're here saying
is broken. Yes, only the one CPU will (explicitly) use those fixmap PTEs
and thus the local invalidate _should_ work. However nothing prohibits
speculation on another CPU from using our fixmap addresses. Which can
lead to the remote CPU populating its TLBs for our fixmap entry.

And, as we've found, there are AMD parts that #MC when there are
mis-matched TLB entries.

So what do we do? mark x86_32 SMP broken?