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 E505F296BCC for ; Sun, 28 Jun 2026 20:49:59 +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=1782679801; cv=none; b=j+mxwBH6UtahvtQ71B1E40cZgAOo+w3LGsQPRObOfm0n3y89iGGT0/9ilmX2Rfy4ktwgWpaqYw8pHTR6sLw4V98FKW7svWeEyT+/ZF6N5iOc+zxzCYuftKFroTaQQyi+vTxnjlkvasBVFFGNEeB8XMPbdxJoQhPtFuPOIPBJdsU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782679801; c=relaxed/simple; bh=5hHkkrsNMZT0O9wtqbdmauroM8dLeoBeYas3cz5fvoE=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=QOVAE1uTi7f5+jNW40kdP4qpvZFzZZRIyZPyRIe8yDtu/nsYrKq25F10S6HW+V0Mi/DT1dVuHjeQ08dydLFi9hpvXbNkDcCocwo5jHzWVT7ZTCHM+mot0hEQCjLZ4SvZJVvgacfBS99eQBPszRPADjH9bThfhC7do5OMTonzDKo= 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=NszmPxQ1; 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="NszmPxQ1" 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 65SKX9Fc2699327 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 28 Jun 2026 13:33:10 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 65SKX9Fc2699327 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026052701; t=1782678791; bh=5hHkkrsNMZT0O9wtqbdmauroM8dLeoBeYas3cz5fvoE=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=NszmPxQ1WPMOaCrJDuL3o5bdzt4WDtZQqs7n+t1PPrTGFuuyBtBSSLx570gYRCxmC VlVcm7JjJ9awHV9T2+rRe4Gky7FaNiSyyyPy18rcPflSt7KwqU2JJF/vatpOwBo846 0Ium/vS+0rYYS5GkfJlHvb/uxJ/llNtEZQroav+qvgjDP5C2IaR4nhJFKoZl/2sraH PBLWr1lHQV3eSWso18CbHuznN+Ed3uJlFru5e89ICel6qwMfFWd3YMPAWujGjzzpa8 eIW76RtLn7y/UTgfyCUC++MrmBm5EhiHFn3SVMgIAstrH0OnkNVBU4fAWT0JZYx4/W nghpja145d9uA== Date: Sun, 28 Jun 2026 13:33:05 -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: <87ldbyhatz.ffs@fw13> References: <20260424191456.2679717-1-stevensd@google.com> <20260424191456.2679717-13-stevensd@google.com> <87zf0hgc3r.ffs@fw13> <87ldbyhatz.ffs@fw13> Message-ID: <888C322E-BF59-4C72-BFD2-2E71FD8605C0@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 28, 2026 9:46:32 AM PDT, Thomas Gleixner wrote: >On Fri, Jun 26 2026 at 21:05, David Stevens wrote: >> On Fri, Jun 26, 2026 at 3:39=E2=80=AFPM Thomas Gleixner wrote: >> That is definitely a situation that could happen, I hadn't thought of >> it=2E Luckily, I don't think we need NMI-safe re-entrancy to handle >> this, since an NMI on SL0 couldn't have interrupted a dynamic stack >> fault=2E > >Correct=2E > >>> As a consequence you copy stack data around to the same place, which >>> should be benign, but it is well understood that memcpy() source and >>> destination areas _must_ not overlap=2E That's UB, no? >>> >>> I know that should not happen, but that doesn't make it less UB :) >> >> 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 switch >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 :)