Received-SPF: pass (google.com: domain of linux-kernel+bounces-99670-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Feedback-ID: ieff94742:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-251-g8332da0bf6-fm-20240305.001-g8332da0b
Precedence: bulk
MIME-Version: 1.0
Message-Id: <ef0419dd-9d7b-4b77-b63a-5f11aaefb570@app.fastmail.com>
In-Reply-To: <bedfa55b-b1d0-4e59-8c94-dbc5f8485a7f@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>
Date: Mon, 11 Mar 2024 16:41:28 -0700
From: "Andy Lutomirski" <luto@kernel.org>
To: "Dave Hansen" <dave.hansen@intel.com>,
 "Pasha Tatashin" <pasha.tatashin@soleen.com>,
 "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
 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>,
 "H. Peter Anvin" <hpa@zytor.com>,
 "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
Content-Type: text/plain

On Mon, Mar 11, 2024, at 4:34 PM, Dave Hansen wrote:
> On 3/11/24 15:17, Andy Lutomirski wrote:
>> I *think* that all x86 implementations won't fill the TLB for a
>> non-accessed page without also setting the accessed bit,
>
> That's my understanding as well.  The SDM is a little more obtuse about it:
>
>> Whenever the processor uses a paging-structure entry as part of
>> linear-address translation, it sets the accessed flag in that entry
>> (if it is not already set).
>
> but it's there.
>
> But if we start needing Accessed=1 to be accurate, clearing those PTEs
> gets more expensive because it needs to be atomic to lock out the page
> walker.  It basically needs to start getting treated similarly to what
> is done for Dirty=1 on userspace PTEs.  Not the end of the world, of
> course, but one more source of overhead.

In my fantasy land where I understand the x86 paging machinery, suppose we're in finish_task_switch(), and suppose prev is Not Horribly Buggy (TM).  In particular, suppose that no other CPU is concurrently (non-speculatively!) accessing prev's stack.  Prev can't be running, because whatever magic lock prevents it from being migrated hasn't been released yet.  (I have no idea what lock this is, but it had darned well better exist so prev isn't migrated before switch_to() even returns.)

So the current CPU is not accessing the memory, and no other CPU is accessing the memory, and BPF doesn't exist, so no one is being utterly daft and a kernel read probe, and perf isn't up to any funny business, etc.  And a CPU will never *speculatively* set the accessed bit (I told you it's fantasy land), so we just do it unlocked:

if (!pte->accessed) {
  *pte = 0;
  reuse the memory;
}

What could possibly go wrong?

I admit this is not the best idea I've ever had, and I will not waste anyone's time by trying very hard to defend it :)