Received-SPF: pass (google.com: domain of linux-kernel+bounces-99722-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Mon, 11 Mar 2024 18:25:56 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
To: Dave Hansen <dave.hansen@intel.com>, Nadav Amit <nadav.amit@gmail.com>,
        Andy Lutomirski <luto@kernel.org>
CC: Pasha Tatashin <pasha.tatashin@soleen.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-mm <linux-mm@kvack.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        the arch/x86 maintainers <x86@kernel.org>,
        Borislav Petkov <bp@alien8.de>, Christian Brauner <brauner@kernel.org>,
        bristot@redhat.com, Ben Segall <bsegall@google.com>,
        Dave Hansen <dave.hansen@linux.intel.com>, dianders@chromium.org,
        dietmar.eggemann@arm.com, eric.devolder@oracle.com, hca@linux.ibm.com,
        "hch@infradead.org" <hch@infradead.org>,
        Jacob Pan <jacob.jun.pan@linux.intel.com>,
        Jason Gunthorpe <jgg@ziepe.ca>, jpoimboe@kernel.org,
        Joerg Roedel <jroedel@suse.de>, juri.lelli@redhat.com,
        Kent Overstreet <kent.overstreet@linux.dev>, kinseyho@google.com,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        lstoakes@gmail.com, mgorman@suse.de, mic@digikod.net,
        michael.christie@oracle.com, Ingo Molnar <mingo@redhat.com>,
        mjguzik@gmail.com, "Michael S. Tsirkin" <mst@redhat.com>,
        Nicholas Piggin <npiggin@gmail.com>,
        "Peter Zijlstra (Intel)" <peterz@infradead.org>,
        Petr Mladek <pmladek@suse.com>,
        Rick P Edgecombe <rick.p.edgecombe@intel.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Suren Baghdasaryan <surenb@google.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Uladzislau Rezki <urezki@gmail.com>, vincent.guittot@linaro.org,
        vschneid@redhat.com
Subject: Re: [RFC 11/14] x86: add support for Dynamic Kernel Stacks
User-Agent: K-9 Mail for Android
In-Reply-To: <dd67a2b9-35ef-4cf8-b303-9e6b8692b390@intel.com>
References: <20240311164638.2015063-1-pasha.tatashin@soleen.com> <20240311164638.2015063-12-pasha.tatashin@soleen.com> <3e180c07-53db-4acb-a75c-1a33447d81af@app.fastmail.com> <bedfa55b-b1d0-4e59-8c94-dbc5f8485a7f@intel.com> <ef0419dd-9d7b-4b77-b63a-5f11aaefb570@app.fastmail.com> <08EFDEDB-7BBB-4D9C-B7E5-D7370EC609BE@gmail.com> <dd67a2b9-35ef-4cf8-b303-9e6b8692b390@intel.com>
Message-ID: <D4D747C5-2B0E-44B0-A550-BA05BE0AF2FA@zytor.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On March 11, 2024 5:53:33 PM PDT, Dave Hansen <dave=2Ehansen@intel=2Ecom> w=
rote:
>On 3/11/24 16:56, Nadav Amit wrote:
>> So you can look on the dirty-bit, which is not being set
>> speculatively and save yourself one problem=2E
>Define "set speculatively"=2E :)
>
>> If software on one logical processor writes to a page while software
>> on another logical processor concurrently clears the R/W flag in the
>> paging-structure entry that maps the page, execution on some
>> processors may result in the entry=E2=80=99s dirty flag being set (due =
to the
>> write on the first logical processor) and the entry=E2=80=99s R/W flag =
being
>> clear (due to the update to the entry on the second logical
>> processor)=2E
>
>In other words, you'll see both a fault *AND* the dirty bit=2E  The write
>never retired and the dirty bit is set=2E
>
>Does that count as being set speculatively?
>
>That's just the behavior that the SDM explicitly admits to=2E

Indeed; both the A and D bits are by design permissive; that is, the hardw=
are can set them at any time=2E

The only guarantees are:

1=2E The hardware will not set the A bit on a not present late, nor the D =
bit on a read only page=2E

2=2E *Provided that the user has invalidated the page entry in the TLB*, h=
ardware guarantees the respective bits will be set before a dependent memor=
y access is made visible=2E Thus the bits are guaranteed to reflect a stric=
t superset of operations performed architecturally=2E