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 732CBC83F04 for ; Wed, 2 Jul 2025 13:28:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA8AF6B00C3; Wed, 2 Jul 2025 09:28:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E7FFD6B00C7; Wed, 2 Jul 2025 09:28:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D6FD26B00C8; Wed, 2 Jul 2025 09:28:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C2F9F6B00C3 for ; Wed, 2 Jul 2025 09:28:15 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3E25310651A for ; Wed, 2 Jul 2025 13:28:15 +0000 (UTC) X-FDA: 83619403350.24.2CDCB8F Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) by imf13.hostedemail.com (Postfix) with ESMTP id 9C1E62000E for ; Wed, 2 Jul 2025 13:28:12 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HrD8LvbB; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf13.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.198.163.15) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751462893; a=rsa-sha256; cv=none; b=QbnIvW+/bhCVnNmxrMjbDYGz7wvY7ihA57GSq+tkDPtV1v+1BZos7pBgXmK5FWyWu6oM89 E0QxZaREMJ3dfLmzO0fJR8YDXM0tFlDsiEOuBvksdz0l8RnyqYUoGPCFSXsvSeEaQjKOAt G56tAp1n7vo+uLSHbBEZhRmG94WQxds= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HrD8LvbB; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf13.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.198.163.15) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751462893; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=QYhGRT2e2xi1TaRDbTyYEC97LjRj/Yl9/MN6W3210/I=; b=Wj6+BXm3eUtYqHCI7GbmnouJb2ORWMhCoIa0pdGjwE+CAgfyltSu00DfPXeOHEvLKQKNDA zG1tZIYWrIBWoBz8XsI/Vu4dkQZ6b76yJipIes9Zv3TxNtB5Kp5wY0i18xuL6KFG8FpSgA Z3CfUpTUc2e3AvBxsxOY1c1a1PqHBpE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751462893; x=1782998893; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=bPtWi2+/IrDUn+HheU/a56H/VJ+K3+rY5j0OYCr0awQ=; b=HrD8LvbBUBKRqueky28w/LYTVDSgIRoqnxo0Cjh+fyIASKx8UpkzLLbw tR4gWRoPkunK9/BbInvKcqOTOizNyRR2cy+fdU45DAlWZIiJ3nH2iogEe mZE1ZH2Qq8UI6cIMaOCqqKVqsgLLlEGoELFyX3uu380JZOLUlD3TyFTXm 0YH4tZ6SVFLqz/VYg8yguusBQ0O0QLQSENkeCrGpbdCFlpTMQ33BbvQ1X MHH20qxD4TROvzfq8bxAAtqt5Vy65FgmSgXTiqdfqVEcY/EEHEKXhhFT9 TW3Vf7pjq5ANEPRJDdiQR4Th59a1BpSgMowxErDVU1l85W7YNP7x8BonL w==; X-CSE-ConnectionGUID: sDu1fgwqREeRjMVyWw1syA== X-CSE-MsgGUID: N9+r5vRqRH6bjifOtsCBwA== X-IronPort-AV: E=McAfee;i="6800,10657,11482"; a="53898822" X-IronPort-AV: E=Sophos;i="6.16,281,1744095600"; d="scan'208";a="53898822" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jul 2025 06:28:11 -0700 X-CSE-ConnectionGUID: ZOBRGeyiRYmGwYNxtTi/IQ== X-CSE-MsgGUID: qgnJ4L6UQQqKVMLd5kpaVQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,281,1744095600"; d="scan'208";a="191244914" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa001.jf.intel.com with ESMTP; 02 Jul 2025 06:27:57 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 9A4071E0; Wed, 02 Jul 2025 16:27:55 +0300 (EEST) Date: Wed, 2 Jul 2025 16:27:55 +0300 From: "Kirill A. Shutemov" To: Sohil Mehta Cc: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , 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 , 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 Message-ID: References: <20250701095849.2360685-1-kirill.shutemov@linux.intel.com> <20250701095849.2360685-15-kirill.shutemov@linux.intel.com> <95dc18fd-73b0-4019-92d2-c0e6aaf22c96@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95dc18fd-73b0-4019-92d2-c0e6aaf22c96@intel.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 9C1E62000E X-Stat-Signature: k7tf4hii1z1b84b8df9pd176zt6ajsga X-Rspam-User: X-HE-Tag: 1751462892-185327 X-HE-Meta: U2FsdGVkX1/3zAeQ/alQ0KgKpckANrvDwxhZnnZw6/Zml/LC/JySWI91hgW6QRLyrmfJoO8V2040imKSqT1CbcK/SbSoBdqbps0fAj5mVoratUz9pp/0aBOGXtWWsC0yE4wHr7bw0VqqBWzAee1xAb5tS4/gLzo3Qqe2vmksO/BVy7aeeQqLvndk53txZg3ojsfObsWVsRl4dDAbSp5vpn3HobvhbyS8xoiBekTdipiE4H3COrEPy6wBUnkHkiiWc0KGBD2JRx1KloIdZXcRxP60U26kLqgzEM78eVS5aqRSPWysU0HboTFJ+xuMDHx3zi2tkRW1rtbRJRHWD+hfTXpMAFdl38OdPLPhTOcem+OXQysYBJCdZvKFbCeCQLEjy71ZOtZbHzN6jIMQT5/PCdMR7jdcSWuQqcuT/354mFZ4uBuBtdhXVmF1kMJV1DTZpJYSa76pFNeb7RKkgKjSR2uAAw7wag73PS2XyGkfy7vAuDa1LJwmTRAMoE7ZKNZehvBW6LWgfmOE4qO6itPoFCBl5rGraT2IRCVIao/ddXNIugmlCl8GifI1J/HoQt5Af29udpdz+l+8gKGNQRospXEBdg+JQRaqGfOqM2QAWLc72cgXgwV7TFUQTXC9ZmqdyifBlQEa6olGD2oXhixtfvhiKqEr0lwtYOVKuNLs/sO4VE9InAb0UmES7wuMts+1MrlbhvtBLRoI4taN+ZX+ca8ScvPMCXCiJbWQKG1hFoRwWlC5xUxegLbQJAdDjTGKbPzkE15jt75V3XFGePvvaoj0cj4CUViWF8JI39opyhNM0jRIkFXJHAmmvoqxfntroxW9sYndA8O9wsiDlxhRFOO5uZxR1DA5gVVPloNyRlmX9OerKmcuZfjCGl90f6F/2aSkNZm4KNBQ5j/F5drZ7bdGlItpp4ekQHFD+3bby2s6bP4BKqQ6Kw== 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 Tue, Jul 01, 2025 at 06:35:40PM -0700, Sohil Mehta wrote: > On 7/1/2025 2:58 AM, Kirill A. Shutemov wrote: > > LASS throws a #GP for any violations except for stack register accesses, > > in which case it throws a #SS instead. Handle this similarly to how other > > LASS violations are handled. > > > > 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 #GP? It can be generated by both kernel and userspace if RSP gets corrupted. So far, do_error_trap() did the trick, handling what has to be handled. LASS requires a bit more, though. > > > In case of FRED, before handling #SS as LASS violation, kernel has to > > check if there's a fixup for the exception. It can address #SS due to > > invalid user context on ERETU. See 5105e7687ad3 ("x86/fred: Fixup > > fault on ERETU by jumping to fred_entrypoint_user") for more details. > > > > Co-developed-by: Alexander Shishkin > > Signed-off-by: Alexander Shishkin > > Signed-off-by: Kirill A. Shutemov > > --- > > arch/x86/kernel/traps.c | 39 +++++++++++++++++++++++++++++++++------ > > 1 file changed, 33 insertions(+), 6 deletions(-) > > > > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c > > index ceb091f17a5b..f9ca5b911141 100644 > > --- a/arch/x86/kernel/traps.c > > +++ b/arch/x86/kernel/traps.c > > @@ -418,12 +418,6 @@ DEFINE_IDTENTRY_ERRORCODE(exc_segment_not_present) > > SIGBUS, 0, NULL); > > } > > > > -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 = "alignment check"; > > @@ -866,6 +860,39 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) > > cond_local_irq_disable(regs); > > } > > > > +#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 = get_kernel_exc_address(regs, &exc_addr); > > + if (hint != EXC_NO_HINT) { > > The brackets are not needed for singular statements. Also the max line > length is longer now. You can fit this all in a single line. I think line split if justified. It is 120 characters long otherwise. And with multi-line statement, brackets help readability. I don't see a reason to change it. > > + printk(SSFSTR ", %s 0x%lx", kernel_exc_hint_help[hint], > > + exc_addr); > > + } > > + > > > + if (hint != EXC_NON_CANONICAL) > > + exc_addr = 0; > > + > > + die_addr(SSFSTR, regs, error_code, exc_addr); > > The variable names in die_addr() should be generalized as well. They > seem to assume the caller to be a #GP handler. Okay, will fold into "x86/traps: Generalize #GP address decode and hint code". > > + 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; > -- Kiryl Shutsemau / Kirill A. Shutemov