From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5804954652 for ; Thu, 18 Jun 2026 23:00:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781823659; cv=none; b=LVqkPursptmA7tV0bXGBmZ2T9dxUSzv/0Zkxx5CYbSElK8hkuxbYDTC8PmPF0ukyj4LcMo79/6knkzPHn9CNdPE+eWkFy4756ae2Z55Gn2qeApvNdeqLHoCxznLuraH27aGlq0IOPTtq0H/HkVDz9N/2hwRuS1l6JNdZD9FDO4k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781823659; c=relaxed/simple; bh=9vbtf3dHPpnTWN7Fl57qIVk+/4NTF0QqI/CpqNbUqfY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LCE5mE3sl16Ex7GLWyBlgQqQrm4WLQhyzMpat+Pu+6Q/ed8xN4rG+VjOWmzWWDFe11u96TBXO9OUjBaS3zcj8T7iwZ4wc7PJrsgIjnuYmpIBpLNPRUYfqueOYMsEgJkvNXnOLuhDELr9824dxLMs/XTTz2JY1Fj2Pg2ir8QWGfU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=fail (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=dwwJelEx reason="signature verification failed"; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="dwwJelEx" Received: from [IPV6:2601:646:8081:7da1:99a0:e0da:db53:8fc0] ([IPv6:2601:646:8081:7da1:99a0:e0da:db53:8fc0]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 65IMSRJV3892479 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 18 Jun 2026 15:28:27 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 65IMSRJV3892479 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026052701; t=1781821710; bh=+CQLyZa+kGZ1jKy62lWGqc1Yb5ykOIz4STFA7tIJWAI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=dwwJelExN+knq2Ai6uFv1+GAdq+HmK4qrLg7r7KJ6SJrJcypiWAa/hgmBGZDaOZjD YQFK58avMBPqFMKrpEVODbyrFoIjz+g4s2DNkyagCPxac3B/y64X5/q3ZC2uRko4Lo akq7uXP7UplNAVV4ZnRImIOxRVn/I7JfK7bqzWNt/fyvm2clphErfHf2yB9+N3IS+d MG3jflJEVXTWrk4rM/Y+uSOrdtExqEYUQx50JrGomOF+RnyNu8PRadl0bV87mYSKh7 qs05+Vgzib/LkiM0piiyC0sHKur9vRbDg9yh08eIe9ofnQj4+pUjWpw+C9G1BjUjHu 4460Atwn4/Rlw== Message-ID: Date: Thu, 18 Jun 2026 15:28:22 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 00/13] Dynamic Kernel Stacks To: Dave Hansen , "Zach O'Keefe" Cc: David Stevens , Pasha Tatashin , Linus Walleij , Will Deacon , Quentin Perret , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Andy Lutomirski , Xin Li , Peter Zijlstra , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Uladzislau Rezki , Kees Cook , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20260424191456.2679717-1-stevensd@google.com> <6369e5ce-74e3-4c68-8053-d7d7d21b6955@zytor.com> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2026-06-18 11:53, Dave Hansen wrote: > On 6/18/26 07:50, Zach O'Keefe wrote: >> Overall, are there any particular painpoints you'd like to see flushed >> out, first? > > Handing exceptions in the kernel is hard. Period. That's the pain point. > Just look at NMIs, #VC, #MC and the rest of that mess. Just look at how > we've moved away from ever taking random page faults in the kernel. Or, > heck, randomly taking faults at *all*. We've concentrated them in very > specific places, not in general code. > > Now you're arguing that the kernel can pretty much take a fault *AND* > allocate memory reliably at any point*. > > I just don't see the collateral in this series to justify that claim. > That is most definitely the zeroth-order thing. Extraordinary claims require extraordinary evidence, and this is certainly an extraordinary claim. In addition to the *massive* maintainability issue, you also have to consider the additional overheads you will now have to deal with in order to avoid deadlocks. Almost every OS that have attempted to swap out kernel stacks have been known to suffer from deadlocks under very high memory load. > The NMI entry code is a disaster because NMIs can happen anywhere. The > #VC code is a disaster because #VCs can happen anywhere. Once #PF can > happen anywhere*, why won't #PF become a disaster? > [...] > * #PF on stack accesses isn't *quite* as bad as NMI or #VC, I'll give > you that. But it's still pretty darn bad. In some ways, they are actually *worse*. #PFs need to be able to sleep, because the common case for a #PF in the kernel is that it touched user space. This means #PF needs to be using IST/SL 0. However, this is obviously incompatible with handling #PFs on the kernel stack itself, so now it needs a stack switch. In the common case, it will then need to demote the #PF back onto the normal execution stack, which is complex in its own right. Now, if you are on a pre-FRED system, the IST entries don't nest, so you absolutely have to make sure you can't get there again through any means whatsoever. With FRED, it isn't quite so dire, but it will still give you lots of fun if that interrupt is one which would like to be demoted off the IRQ stack. > It would be a completely different story if there was a track record of > finding and fixing bugs in the x86 entry code from the authors of this > series. But I don't think I've ever seen a single email from your folks > before this, much less a review tag or a patch. I'd be much happier if > you got Andy L's blessing on this, for example. > >> How would you like to proceed? Would explicitly marking this as an >> experimental config, in the interim, be more attractive? > No. > > The enemy here is complexity. *Maintenance* complexity. Being able to > compile out some of the complexity helps with debugging. But it doesn't > help maintaining the code. Indeed. Paravirtualization is a great example of how this works. The PV hooks in the kernel are still a maintenance nightmare 20 years after they were introduced, and mostly that cost is not borne by the people who introduced and benefited from them. -hpa