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:   Sat, 16 May 2020 12:35:18 +1000
From:   Nicholas Piggin <npiggin@gmail.com>
Subject: Re: Possibility of conflicting memory types in lazier TLB mode?
To:     Rik van Riel <riel@surriel.com>
Cc:     linux-kernel@vger.kernel.org,
        Peter Zijlstra <peterz@infradead.org>, x86@kernel.org
References: <1589523957.s4pf3vd48l.astroid@bobo.none>
        <3b217554a8a337de544482d20ddf8f2152559cd3.camel@surriel.com>
In-Reply-To: <3b217554a8a337de544482d20ddf8f2152559cd3.camel@surriel.com>
MIME-Version: 1.0
Message-Id: <1589595735.4zyv4epfsj.astroid@bobo.none>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Excerpts from Rik van Riel's message of May 16, 2020 5:24 am:
> On Fri, 2020-05-15 at 16:50 +1000, Nicholas Piggin wrote:
>>=20
>> 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?
>>=20
>> 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?
>=20
> On x86, all stores become visible in-order globally.
>=20
> I suspect that
> means any pending stores in the queue
> would become visible to the rest of the system before
> the store to the "current" cpu-local variable, as
> well as other writes from the context switch code
> become visible to the rest of the system.
>=20
> Is that too naive a way of preventing the scenario you
> describe?
>=20
> What am I overlooking?

I'm concerned if the physical address gets mapped with different=20
cacheability attributes where that ordering is not enforced by cache=20
coherency

 "The PAT allows any memory type to be specified in the page tables, and=20
 therefore it is possible to have a single physical page mapped to two=20
 or more different linear addresses, each with different memory types.=20
 Intel does not support this practice because it may lead to undefined=20
 operations that can result in a system failure. In particular, a WC=20
 page must never be aliased to a cacheable page because WC writes may=20
 not check the processor caches." -- Vol. 3A 11-35

Maybe I'm over thinking it, and this would never happen anyway because=20
if anyone were to map a RAM page WC, they might always have to ensure=20
all processor caches are flushed first anyway so perhaps this is just a=20
non-issue?

Thanks,
Nick