Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 15 May 2020 16:50:19 +1000
From:   Nicholas Piggin <npiggin@gmail.com>
Subject: Possibility of conflicting memory types in lazier TLB mode?
To:     Rik van Riel <riel@surriel.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        linux-kernel@vger.kernel.org, x86@kernel.org
MIME-Version: 1.0
Message-Id: <1589523957.s4pf3vd48l.astroid@bobo.none>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Rik,

Commit 145f573b89a62 ("Make lazy TLB mode lazier").

A couple of questions here (and I don't know the x86 architecture too=20
well let alone the ASID stuff, so bear with me). I'm assuming, and it=20
appears to be in the x86 manual that you can't map the same physical=20
page with conflicting memory types on different processors in general
(or in different ASIDs on the same processor?)

Firstly, the freed_tables check, that's to prevent CPUs in the lazy mode=20
with this mm loaded in their ASID from bringing in new translations=20
based on random "stuff" if they happen to speculatively load userspace=20
addresses (but in lazy mode they would never explicitly load such=20
addresses), right?

I'm guessing that's a problem but the changed pte case is not, is=20
because the table walker is going to barf if it sees garbage, but a=20
valid pte is okay.

Now the intel manual says conflicting attributes are bad because you'll=20
lose cache coherency on stores. But the speculative accesses from the=20
lazy thread will never push stores to cache coherency and result of the=20
loads doesn't matter, so maybe that's how this special case avoids the
problem.

But what about if there are (real, not speculative) stores in the store=20
queue still on the lazy thread from when it was switched, that have not=20
yet become coherent? The page is freed by another CPU and reallocated
for something that maps it as nocache. Do you have a coherency problem=20
there?

Ensuring the store queue is drained when switching to lazy seems like it=20
would fix it, maybe context switch code does that already or you have=20
some other trick or reason it's not a problem. Am I way off base here?

Thanks,
Nick