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 C322038945D for ; Mon, 29 Jun 2026 14:52:58 +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=1782744780; cv=none; b=M1gwrBhe2syrE/Ml9CHbkMpf+h1o5cBLeSUQ2MRHUKwRC4hhlRYcft/9A54+a16e+t5U3FXbb9QBFjlowPO6bMhbPnV5P99G4gfunvft1O18aee7qi3cBp39+ohJcBcpWN3YobqfhxA4mWXSZT89KfV2ZKBci1xQ/yNC3yNEr/U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782744780; c=relaxed/simple; bh=KwYRkjNitWaWf/u5dgSEWkgJNU+anMwoiUn3RtlC/o8=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=ttg7t2OUi19RanixWF/jyyRiDp2cXjEX8Ae1MMJ7Df4VhbuEnBdGKv+IgDUgi4URbVkooyX/rU8wkGpQ64lIvDiPSqiTEdhBXM8v0g3FQHdSoR/ioYAFX+NnttT+9wOx3nDfPYkPXflyTs1UEXgpsCL43onfco+7CzX42S6jMyc= 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=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=dK4IOP/K; 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=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="dK4IOP/K" Received: from ehlo.thunderbird.net (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 65TEq8ww461421 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 29 Jun 2026 07:52:09 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 65TEq8ww461421 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026062701; t=1782744730; bh=KwYRkjNitWaWf/u5dgSEWkgJNU+anMwoiUn3RtlC/o8=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=dK4IOP/KT91qfq5gAJIymtQhJ+E7dYNwkOpkGSFgllbgcpqTc3JKX058I2Bc1mJGT 5BLtdRaLkOf7Z9bsdCGW+kuvm8/df5mlJJN/MZoc27YJbOHTNLPekPQf5MgJbsy8Xn U8JamV7JSNRvHsgOOrzydpa6ETrcW9OhWT93JyTS0BqVIxeeHrzGCt0uAlI+9VRGqQ ExcTM9VnV+hQQqnh3KHSNZaLRtr6+v1U5EwkwdwG+HkZmdV4IbOoNWndzyJ2nKsGCH oJ9iThzxy2YtJqCu0vqpdiDH88e/i4pFmGomxB7lRXrbqarENlhjcjPV4KNtXOCcHO gBaTKM+bA/uEA== Date: Mon, 29 Jun 2026 07:52:02 -0700 From: "H. Peter Anvin" To: Thomas Gleixner , David Stevens CC: Pasha Tatashin , Linus Walleij , Will Deacon , Quentin Perret , 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 Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v2_12/13=5D_x86=3A_Add_suppor?= =?US-ASCII?Q?t_for_dynamic_kernel_stacks_via_FRED?= User-Agent: K-9 Mail for Android In-Reply-To: <878q7xspqu.ffs@fw13> References: <20260424191456.2679717-1-stevensd@google.com> <20260424191456.2679717-13-stevensd@google.com> <87zf0hgc3r.ffs@fw13> <87ldbyhatz.ffs@fw13> <888C322E-BF59-4C72-BFD2-2E71FD8605C0@zytor.com> <878q7xspqu.ffs@fw13> Message-ID: <7D930EA3-54D1-41CD-B547-8A2A69F89142@zytor.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On June 29, 2026 1:41:13 AM PDT, Thomas Gleixner wrote: >On Sun, Jun 28 2026 at 13:33, H=2E Peter Anvin wrote: >> On June 28, 2026 9:46:32 AM PDT, Thomas Gleixner wr= ote: >>>> That sort of fault would probably end up either with a >>>> page_fault_oops() or risk a context switch with SL>0, but we shouldn'= t >>>> make debugging harder with UB=2E >>> >>>Definitely not :) >>> >>>You can avoid quite some of the problems right in the ASM entry code=2E >>>Instead of checking event type/vector and then going to the stack switc= h >>>logic, you can check the stack level on which the event happened >>>first=2E If it's not 0, then there is nothing to do=2E >>> >>> >> >> To be fair, for this *specific* case, memmove() does exist for a reason= :) > >It does, but why bother doing actual work, if you know upfront that it's >not required :) Of course=2E=20 Then there is the very open question if this thing has legs at all=2E I'm = still interested in using SL1 for the interrupt stack as I think that could= be a performance boost=2E