Re: [RFC 11/14] x86: add support for Dynamic Kernel Stacks

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
Date: Mon, 11 Mar 2024 18:25:56 -0700	[thread overview]
Message-ID: <D4D747C5-2B0E-44B0-A550-BA05BE0AF2FA@zytor.com> (raw)
In-Reply-To: <dd67a2b9-35ef-4cf8-b303-9e6b8692b390@intel.com>

On March 11, 2024 5:53:33 PM PDT, Dave Hansen <dave.hansen@intel.com> wrote:
>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.
>Define "set speculatively". :)
>
>> 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’s dirty flag being set (due to the
>> write on the first logical processor) and the entry’s R/W flag being
>> clear (due to the update to the entry on the second logical
>> processor).
>
>In other words, you'll see both a fault *AND* the dirty bit.  The write
>never retired and the dirty bit is set.
>
>Does that count as being set speculatively?
>
>That's just the behavior that the SDM explicitly admits to.

Indeed; both the A and D bits are by design permissive; that is, the hardware can set them at any time.

The only guarantees are:

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

2. *Provided that the user has invalidated the page entry in the TLB*, hardware guarantees the respective bits will be set before a dependent memory access is made visible. Thus the bits are guaranteed to reflect a strict superset of operations performed architecturally.