From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F9C6C7EE30 for ; Wed, 2 Jul 2025 02:07:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D08166B00AB; Tue, 1 Jul 2025 22:07:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CB88E6B00AD; Tue, 1 Jul 2025 22:07:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA7AF6B00AF; Tue, 1 Jul 2025 22:07:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A4F326B00AB for ; Tue, 1 Jul 2025 22:07:03 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4DD76160703 for ; Wed, 2 Jul 2025 02:07:03 +0000 (UTC) X-FDA: 83617686726.27.69BBD83 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) by imf03.hostedemail.com (Postfix) with ESMTP id A29B520009 for ; Wed, 2 Jul 2025 02:07:01 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=zytor.com header.s=2025062101 header.b=HVk+Nym7; dmarc=pass (policy=none) header.from=zytor.com; spf=pass (imf03.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751422021; a=rsa-sha256; cv=none; b=WKwj39jzfyP1lc+yw3rBPgCYYZmTMJOOCvNLex6FW6ugy3Tr5ii7sYBrITgxQhdPvdBgEp isH0APLl8RUtUl0ZZ4EQN7W8QLtbtHO2+VgjjSXD478ifrxGEz/5zWjti1YhblKXZx9jHz O4OXh2OQI9B5LZyHiV5zkpzZ+gNYTzA= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=zytor.com header.s=2025062101 header.b=HVk+Nym7; dmarc=pass (policy=none) header.from=zytor.com; spf=pass (imf03.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751422021; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=i69d9Gb3Xi/Rw/rkK5nIxcEDPVZQe+0UUT5XjAKGRLM=; b=QoKygA+q27Fppt5wyEh913JIp3xLC1CIuD2dScNUXtj6C+Cr2xitTkI2mUJMiyGMJVqMs6 B9Gq4hg3jUxAw6HdNleKW5K5pjpJKPl0qO3KtxYkUyoZ4KBgZLzyv1WQ/5ZDQ24Ly3Xhfz FizE8LKpF960/OeXkRUYWRm1PaXz3FE= Received: from [127.0.0.1] (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 562269O4460250 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 1 Jul 2025 19:06:09 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 562269O4460250 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025062101; t=1751421972; bh=i69d9Gb3Xi/Rw/rkK5nIxcEDPVZQe+0UUT5XjAKGRLM=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=HVk+Nym7wO5i6CFYox0su0fxzPEjdm2+dpWmWYO8YnKdFvs55NgQV2uQvMsku8PPU 7xiGu46d7uG8YNQ1lk0MNWXKTwJUDPHgBDChr+tO5nsw0Oe55figZiz2ePOsL7yiE6 UP3KGSpLSbhQVcTgJfSPeRCZX3G1QM07A7ta1CkwwZps9AUqdl+h0Wj6KX9TXF7SLC /F6AdsIJPkqgNOtBeAPmLFciX6ezcifFVFG0DpoEjNzbyV59yIH4iA6U53YAV4AtI+ eCb3DiTQs9mi/rpSsPWcdtOMWwYN/aJoxTR+oMK8+ahZhyl6aLWZzTa6zcqGc1ozWn A3RYyCaMG94Jg== Date: Tue, 01 Jul 2025 19:06:10 -0700 From: "H. Peter Anvin" To: Sohil Mehta , "Kirill A. Shutemov" , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin CC: Jonathan Corbet , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv8 14/17] x86/traps: Handle LASS thrown #SS User-Agent: K-9 Mail for Android In-Reply-To: <95dc18fd-73b0-4019-92d2-c0e6aaf22c96@intel.com> References: <20250701095849.2360685-1-kirill.shutemov@linux.intel.com> <20250701095849.2360685-15-kirill.shutemov@linux.intel.com> <95dc18fd-73b0-4019-92d2-c0e6aaf22c96@intel.com> Message-ID: <4DE45AFD-C1E0-4FB8-BE01-44A72C5C6E1E@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: A29B520009 X-Stat-Signature: up5tf1yrds63jcdsh484yi85r38zink7 X-Rspam-User: X-HE-Tag: 1751422021-7063 X-HE-Meta: U2FsdGVkX19ygrU2OKi1anZnz/Q2Hvi6P0yM9vJ9oaCUO/+SeGQsvPPRhYMqVWeikpQBzOk8gqYmgI6q9OTN+TKJaBBpaqKBzjNOcGU9YxCop1YHbUP8SmAbq1WiIiH3zK1NNg76JKKFPSF6mdT7ZG9qv6UBm0ns20oFMN7SNZcZAZ2Gw8EbVW++i5tldqnUJkfw8tlawIZZXOQ+iEvxngTk4Osjqt/UZNrXI+q4WZOtp/xeB73sA2ciWF2kbaPRig/3zsFtogcs72y9t/hip+JCzmANXSeukFCrI53S/f2kfzkDv3MZ22o2ZHGsIFkuV+qdRyT6sGhapaSuagYxrPLdp7mAGYLuFk3IggK4PoSl4NrnOwGduY6dMQnrWZjRfm6+bNmJfY4q1UVQhHA5RsEv9tRLIua+HWcIYc53GSWcjYB2v2y8C2/322s4KBi1yh1N0uT2ET9l9JZZCXEGu2OYOmDLKGVlEWVe/2rYoqjxo569gl3zrAo7q2K/L/NomI15wDcno3+oSiQx5j0sk+fx9X4PTRX+E3wooKw1cNXIoFQGIuL0cA802GtResSJhEKkcnRTJKaPQa0eamKjRVa30SftQAg5iKWxRFNmI+JD7JsQOl0aMem2kHD3KUdsJ2e+WkENoM5Yup5GAn1uDrpM7gRPFW9ZM9mZEkG53MoGswdQelxi5GCuR+UHNPeIZYvtAe90+hp9Sac4nSjiUCRcvu09pM2BK6opvPiqvY5jlKjFkTh+W7L+zcHHJQODlCPjnP+rIt36xMd677yiId30mDzFkV4kgmNgyu7hSscIBOWmzZLcizc2/R4A7VaHuMCK9DrK8vbwCKCvFx3i3zWDl68X6wZjnGbF4iR9HybrMwLAS7QgedaGOiksbdyBbPBB07G32T2QvoKwEYNzEHIaoB1YmYYLgUHyU4uOBSgHVSt2RPZngmMfhGHrt9looqKM3BjrV3dHkqRaE2B 05oc8hpS kirg0HGOfFpqm4yYiA3Q1M5bkwv6CRi6ITKkC3QUCj1ZDKgu1wJKbRvJf0wxQXWRFI3S2SIqLVJ2V6/Q= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On July 1, 2025 6:35:40 PM PDT, Sohil Mehta wro= te: >On 7/1/2025 2:58 AM, Kirill A=2E Shutemov wrote: >> LASS throws a #GP for any violations except for stack register accesses= , >> in which case it throws a #SS instead=2E Handle this similarly to how o= ther >> LASS violations are handled=2E >>=20 > >Maybe I've misunderstood something: > >Is the underlying assumption here that #SS were previously only >generated by userspace, but now they can also be generated by the >kernel? And we want the kernel generated #SS to behave the same as the #G= P? > >> In case of FRED, before handling #SS as LASS violation, kernel has to >> check if there's a fixup for the exception=2E It can address #SS due to >> invalid user context on ERETU=2E See 5105e7687ad3 ("x86/fred: Fixup >> fault on ERETU by jumping to fred_entrypoint_user") for more details=2E >>=20 >> Co-developed-by: Alexander Shishkin >> Signed-off-by: Alexander Shishkin >> Signed-off-by: Kirill A=2E Shutemov >> --- >> arch/x86/kernel/traps=2Ec | 39 +++++++++++++++++++++++++++++++++------ >> 1 file changed, 33 insertions(+), 6 deletions(-) >>=20 >> diff --git a/arch/x86/kernel/traps=2Ec b/arch/x86/kernel/traps=2Ec >> index ceb091f17a5b=2E=2Ef9ca5b911141 100644 >> --- a/arch/x86/kernel/traps=2Ec >> +++ b/arch/x86/kernel/traps=2Ec >> @@ -418,12 +418,6 @@ DEFINE_IDTENTRY_ERRORCODE(exc_segment_not_present) >> SIGBUS, 0, NULL); >> } >> =20 >> -DEFINE_IDTENTRY_ERRORCODE(exc_stack_segment) >> -{ >> - do_error_trap(regs, error_code, "stack segment", X86_TRAP_SS, SIGBUS, >> - 0, NULL); >> -} >> - >> DEFINE_IDTENTRY_ERRORCODE(exc_alignment_check) >> { >> char *str =3D "alignment check"; >> @@ -866,6 +860,39 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) >> cond_local_irq_disable(regs); >> } >> =20 >> +#define SSFSTR "stack segment fault" >> + >> +DEFINE_IDTENTRY_ERRORCODE(exc_stack_segment) >> +{ >> + if (user_mode(regs)) >> + goto error_trap; >> + >> + if (cpu_feature_enabled(X86_FEATURE_FRED) && >> + fixup_exception(regs, X86_TRAP_SS, error_code, 0)) >> + return; >> + >> + if (cpu_feature_enabled(X86_FEATURE_LASS)) { >> + enum kernel_exc_hint hint; >> + unsigned long exc_addr; >> + >> + hint =3D get_kernel_exc_address(regs, &exc_addr); >> + if (hint !=3D EXC_NO_HINT) { > >The brackets are not needed for singular statements=2E Also the max line >length is longer now=2E You can fit this all in a single line=2E > >> + printk(SSFSTR ", %s 0x%lx", kernel_exc_hint_help[hint], >> + exc_addr); >> + } >> + > >> + if (hint !=3D EXC_NON_CANONICAL) >> + exc_addr =3D 0; >> + >> + die_addr(SSFSTR, regs, error_code, exc_addr); > >The variable names in die_addr() should be generalized as well=2E They >seem to assume the caller to be a #GP handler=2E > >> + return; >> + } >> + >> +error_trap: >> + do_error_trap(regs, error_code, "stack segment", X86_TRAP_SS, SIGBUS, >> + 0, NULL); >> +} >> + >> static bool do_int3(struct pt_regs *regs) >> { >> int res; > Note: for a FRED system, ERETU can generate #SS for a non-canonical user s= pace RSP even in the absence of LASS, so if that is not currently handled t= hat is an active bug=2E