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

From: Thomas Gleixner <tglx@linutronix.de>
To: Pasha Tatashin <pasha.tatashin@soleen.com>,
	Andy Lutomirski <luto@kernel.org>
Cc: 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>,
	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: Tue, 12 Mar 2024 00:33:58 +0100	[thread overview]
Message-ID: <87frwwpcm1.ffs@tglx> (raw)
In-Reply-To: <CA+CK2bA22AP2jrbHjdN8nYFbYX2xJXQt+=4G3Rjw_Lyn5NOyKA@mail.gmail.com>

On Mon, Mar 11 2024 at 19:10, Pasha Tatashin wrote:
> On Mon, Mar 11, 2024 at 6:17 PM Andy Lutomirski <luto@kernel.org> wrote:
>> Also, I think the whole memory allocation concept in this whole
>> series is a bit odd.  Fundamentally, we *can't* block on these stack
>> faults -- we may be in a context where blocking will deadlock.  We
>> may be in the page allocator.  Panicing due to kernel stack
>> allocation would be very unpleasant.
>
> We never block during handling stack faults. There's a per-CPU page
> pool, guaranteeing availability for the faulting thread. The thread
> simply takes pages from this per-CPU data structure and refills the
> pool when leaving the CPU. The faulting routine is efficient,
> requiring a fixed number of loads without any locks, stalling, or even
> cmpxchg operations.

Is this true for any context including nested exceptions and #NMI?

Thanks,

        tglx