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 57D45C77B7C for ; Thu, 3 Jul 2025 11:31:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E4E306B00FD; Thu, 3 Jul 2025 07:31:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E25DF6B0102; Thu, 3 Jul 2025 07:31:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D3C1C6B0107; Thu, 3 Jul 2025 07:31:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C07D86B00FD for ; Thu, 3 Jul 2025 07:31:49 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 717051CA54E for ; Thu, 3 Jul 2025 11:31:49 +0000 (UTC) X-FDA: 83622738738.24.0664F01 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) by imf23.hostedemail.com (Postfix) with ESMTP id DAAC9140004 for ; Thu, 3 Jul 2025 11:31:46 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=icvujwCm; spf=none (imf23.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.21) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751542307; 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=rihjzH2IIIIxTJJq2xd/cije/ZRxoWJR+Ytr8AHK2/A=; b=NWx7oUD+458cM53JP8ekOicpKLugmRXFvFUVJad/MvOsp4vghHlc8xgG+yof1KOZGg9xep FEPWP/t4S5vPX82c0uBm7ieQSJ76eRnKilb5QPtglPRYOH/ZGACH4ev46hmvUT/ImiQRLj DcZBB+ndZrX1jf0KKzcOd/EgHwpYMz4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751542307; a=rsa-sha256; cv=none; b=72mrSw8f7UFzrl4rua0oAPOZLrfxgkApMRG4dAd0stGk2/giJBnGmLC8PbG4YF+1OFfUUG FEilSfz0UlIGxMNHAZrYcoheyvQqfqUm3LuByw0YO8mJIdeJZvxPxtFrjiMbPIFKzsFAKo BL/vDKmNqJ1tOHZXIPBAYvUy0KI/MEY= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=icvujwCm; spf=none (imf23.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.21) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751542307; x=1783078307; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=mz2HO5e+m0EVO4Bso9dOWmH5VXn5tebaRN4tyuLfYyQ=; b=icvujwCmzoZiEcBfrizQDS2rg7NbkGkB10DL01IzPoFPIjf1224AdHAg lWP1u9Ygy4G8zV9W5Io0Ce4Kk63AEH+TlCzfV+DsP553xACOJHOnA64A5 o2fDl+JBU36nfLKnVhCyx9n7H2p66JBhXVQiBlUcs1UtiYsMNZF/rwC1N Woe7QvFlovKZAEoESJLS+NIqgTGZdMPBWBr8j4zvdtVf0sXzmQ80B4+Qz 7/Ljalq5URRFqlGoJT2kU8AdB5cN/fkQFYsOxjBebE4AiWUZNWdmoRL4R iBTSjxcXRts+dEA3PwaoG4h1hgJ1zyhBmYnIob4X3mLtrePjj3av3uboi g==; X-CSE-ConnectionGUID: CLAQNmq7T6K00uZsaEd84A== X-CSE-MsgGUID: iqAHGH/zSq25vS2mw7W6wg== X-IronPort-AV: E=McAfee;i="6800,10657,11482"; a="53731260" X-IronPort-AV: E=Sophos;i="6.16,284,1744095600"; d="scan'208";a="53731260" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jul 2025 04:31:46 -0700 X-CSE-ConnectionGUID: Hol9m/2jRjWHXEvh17EZ8g== X-CSE-MsgGUID: ey2HETopSV6Moa5CZajchA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,284,1744095600"; d="scan'208";a="154920492" Received: from black.fi.intel.com ([10.237.72.28]) by fmviesa008.fm.intel.com with ESMTP; 03 Jul 2025 04:31:35 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 4EA371E0; Thu, 03 Jul 2025 14:31:33 +0300 (EEST) Date: Thu, 3 Jul 2025 14:31:33 +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: X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: DAAC9140004 X-Stat-Signature: 6r33bkhuhjprah9tyug11fgqgps9gc6j X-HE-Tag: 1751542306-264063 X-HE-Meta: U2FsdGVkX18XYluMnaURMBT8+ZA9NDAN60ITNRF7BhRBLGZp+qUkM+5AvUfraPTgYmsVoqGtPw5IE0eSn5NgpwwLRvuwoD8e3H/SvgDALD8gVkL8YTiGr14SYgM/91fCPony0xhlB1/43jYYzIon0niuwyslMjq3h57wbhkq4+cERj2HlzPAII+n/9lxdHp/C05x3Cb/XEI4UVMtOMGsxM3Z9uI4xsdgV4Vnx+eRplXd9M2tyl2UAbj3D8yWGl/rHNGEuGgAyK7x3wwGruBQo7yWxid5wbQHtZFaYASi/GdQvvpaL6uu7hP3SE2Fp5zwf5ffOwjT9KZ8KASCGMbAHDlegGYNOXnMCIJuR+xTbyM/hqDJo/GbzHTMqz990mZklaYP9jdDdGOeDqWB7EPo58ik75nDdYwUBArH7tqV0WAB4KQUgXsSSabLUiIuaU5R3EKRaBhs4APVE9yJ+AKJ3Fel09AFNsDXfjzKEAf5jBzgdroT5gYMoaVSKOZyRu0DNTH/KBeiqRi9OYFPWjZx2ZLlgoj7864fmrCy19g/dCXsfsG+g7L9/Mm4BX9Ue3JRZz6KKp/TLAlg87ebQRQYke6WEmj2cORk7BcSDT46GIPqXHuRI/tawNWXTcBeoxAAhLRXWfW/8f3lP8zQEdTJBpcHkUel/FT2t7BEUJjtaC3sga6q35M/RbRG73SvgjDgOrSWQ3GYqJVpRY2dWVHMU950yQuNydNLD66ec1hHzR6BukHjAbwKnpwwFPKAOVsisBmv5I95XGfCW09VkTWOSMlMw0FyIzrkBuvkTVJ5R+NIDMqlpXxEhNw9D2D+8XkBeZOklCmxzZRwaQzhFduxyryzyLmHAQvgxWk2V2eXJMp+i9gNbnuiwhdYnsL431920lTx5K/SfMXfGk4e2JVLz5KlaTUqB77u0Pqpb6USmnK4oFyeJGS+NqSushvtrvaGT/BB/oyv6NztCJ/Ag6X ZCvkjpPa fma0qsgeXYMQoGQjv4DtS7gmhfpd0r+Nn5ToQXSWRW7HVcmDi9tfScUflqUC8WAK64Uzx9CWuPUw5Rk26z563RyWf7SeILdHkH6qHl/jGBGJIiukkqeuYYhPKZRCJaXkeVv8exnL8/248jFSoB+F4QcvPUEyo4j+XBt734liEE+ZQBd65VuyzQ16woXoSN6fks+BKFbdZaABo4XKLVGgVzLgis6jCqVCuqELZVlANRXn5gKj4KpXRdlCiXaRdNw3cFLruTA4vjp0R5w4= 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 Wed, Jul 02, 2025 at 01:05:17PM -0700, Sohil Mehta wrote: > On 7/2/2025 6:27 AM, Kirill A. Shutemov wrote: > > >> > >> 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. > > > Thank you for the information! The discussion in the other thread helped > clarify my confusion about the new FRED specific fixup outside the LASS > check. > > IIUC, for kernel generated #SS, the prior code in do_error_trap() > would've done a few things such as notify_die() and > cond_local_irq_enable() before calling die(). cond_local_irq_enable() need to happen if we want to do something sleepable during exception handling. It is not the case here. notify_die() will be called die_addr()->__die_body()->notify_die(). > The new code now directly calls die_addr(). Are we changing the behavior > for legacy kernel #SS? Also, why don't we need those calls for the new > LASS #SS? do_error_trap() provides catch-all handling for unallowed-thing-happened exception handling in either kernel or userspace. We can take simpler path for fatal in-kernel exception. Following #GP logic matches what we need. -- Kiryl Shutsemau / Kirill A. Shutemov