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 07ECFC7EE31 for ; Fri, 27 Jun 2025 10:27:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9C24A6B00CF; Fri, 27 Jun 2025 06:27:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 96BFE6B00D0; Fri, 27 Jun 2025 06:27:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 834896B00D1; Fri, 27 Jun 2025 06:27:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 73FFA6B00CF for ; Fri, 27 Jun 2025 06:27:57 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1E04A1405BC for ; Fri, 27 Jun 2025 10:27:57 +0000 (UTC) X-FDA: 83600804994.16.8EE86EC Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) by imf02.hostedemail.com (Postfix) with ESMTP id D320980006 for ; Fri, 27 Jun 2025 10:27:54 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="YEM/lJBX"; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf02.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.14) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751020075; a=rsa-sha256; cv=none; b=qLJaD0PKLgltChqGJHzMNXuuDOTuDZH1rpJ5xkaxcMYPHQ0yXd5xs+imooIX9Ve2b/nNsX cj2oqw7sMpuJvl6VYVIpHqedjGKffAyfmpBmm8OV6BmQh4wgDJOfLsOOhYDE/sNn84KMS/ OWGcL49qymCLqNxnEybz8/WDeK3d3xI= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="YEM/lJBX"; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf02.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.14) 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=1751020075; 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=ZYSwOxsdvD/DFlYDO47z8tKVmDzNRrljgQ88Okk4VLk=; b=M3KXRa6UfVTSorb2VTcg8grey04u/bL0KlmG/tGc9FucAwgNc1bz3fGIhGWUX3dfnXcZ3W tCC9VuJZSHwRyufEIvlur1bFRamMeMpVcE0RWRBow/NHNyUwHkz1VSC589otlUsrQqCY56 WhuR9T648+T61bwUXJ96MyJ0ZtXSpvE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751020076; x=1782556076; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=kERVEwZGohcYrv9h5JZQFR9MdOFRWgsOAV17tKHDXTA=; b=YEM/lJBXHhrJJnM73SvuIDgSTgjEH9JxLx/M8iT4IJKussmMM2htUoKT UJ49mLezHy0G1+tv6MACi5EkhrGl2mpCV0yK470+VTn9NYdLRwjDKckjz L1E1dVmdID5MTf9J1sUJoU0ac74EsLq9QWle4O+SD5hBarR6+sgJ8nAC4 +acCQgg1DbxlJkXAdknR1k11FW+2TXubyt0mmchSLee0DBurLqfBWbJ+p gIyEsPNW5OS2m6o6DWSF15mjvO24rWS+lfynMY8BiTF2Z+I9rE+Z0pyrI r3NKWkNH0zu5NChqLkYZG2lZjlBr5xjNZJk/flqilu84YbNBHt7vpkJm4 A==; X-CSE-ConnectionGUID: shsTDiobTsqqbYi2fJTLFA== X-CSE-MsgGUID: +p3N/hr+QFS/D7APsT6fQQ== X-IronPort-AV: E=McAfee;i="6800,10657,11476"; a="57114599" X-IronPort-AV: E=Sophos;i="6.16,270,1744095600"; d="scan'208";a="57114599" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2025 03:27:54 -0700 X-CSE-ConnectionGUID: 45S+G8gQRbyYlPm+P/YH0w== X-CSE-MsgGUID: hDSUJ8eMQpeCgLp4Qi/CVw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,270,1744095600"; d="scan'208";a="156817225" Received: from black.fi.intel.com ([10.237.72.28]) by fmviesa003.fm.intel.com with ESMTP; 27 Jun 2025 03:27:42 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 237C56A; Fri, 27 Jun 2025 13:27:41 +0300 (EEST) Date: Fri, 27 Jun 2025 13:27:41 +0300 From: "Kirill A. Shutemov" To: Dave Hansen Cc: Peter Zijlstra , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , 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 , Sohil Mehta , 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: [PATCHv7 03/16] x86/alternatives: Disable LASS when patching kernel alternatives Message-ID: References: <20250625125112.3943745-1-kirill.shutemov@linux.intel.com> <20250625125112.3943745-5-kirill.shutemov@linux.intel.com> <20250626134921.GK1613200@noisy.programming.kicks-ass.net> <170dbb93-e9d9-4bd4-b56c-502841c21cd3@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <170dbb93-e9d9-4bd4-b56c-502841c21cd3@intel.com> X-Rspam-User: X-Stat-Signature: aw9e95ueji96oh17mfx9wp575c7dcja4 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D320980006 X-HE-Tag: 1751020074-45645 X-HE-Meta: U2FsdGVkX1/Uw3HrHQMVVn6S3xnOvmG1t55DrSgI6ZYs/5cAIJMV6obLWlp5SYk1aVqH7jfN0Gf8NGhWsz2oOiZZaOVenRxGsKTsM1Gd08/n6H5lDnxxGhJdowgXusX3SiYpWMUEvgrDIXfkDF+skqIZf2EGvq2Ca6f2jo5Nn8iTHcDgf/KX3wGHTHZtdWcDixlG+/q8rLI6O3XzGwsUPx8er+OfgtzVpmodwGDqb53a1klRodwq71h5tV1LeRGtOjQFuhNsN6g72fFVl7W82mPl4wsP2GMvl5UmGjfh9iIy1xjY7U9XkPD2nQ+Uk3Qfzhu2onYDYBuwz2zix+AzCPhE8lI52z55IttR25TBI3plVNDx3tr+lssVBkIU8UwrZCkj6ju7eu7ZnXkAiM+R+iqROaK/8k8EIbP/agp749PzHqM7SndtJZLpa1RrLEgvBnUfvwK0NPLdVJO4ZO6gf4YO306/YijVXZrVnckIMTYGnzCb81XJw8y1gk81m7y3NGXQjPA240IsEfl9UTfVEOzqG1r/yWpEgImIJcZkjjuzQbz5JSXOEddHZGV2usC55P4IyCPX0vX8E0hYn7c+syThHoJcDIesnbSJHf/FpiFDdT5lR2MxrK88EmRrUNCRRugqAjpn0ndVnJLjJej3Yhi9yLc/f3zyEPu3UzHCD55UGWvOovA5QqeDLaeUe55b8okEBBjvKrl1F0qy3idvDpxpO0TEnuYb6aTqRUFy1myPnhvskakyn5oGfzL7a5Inixxx/+V4iqC8TYdvu1OLoUyCWBRNf5XUk2769xQe0+/c8OTKWBz7oJcEjzg4HXQdDp66aawEBUwTKaV36ITiIsvR0ZxbwV8cbBarislMrZFGXJolmvXhRbl+E2HgJmMnEBUiHhySNpG5gvLY8iLpmn9vciA+yalOnqzVnnA8OMbjbMQaV4YZXjo5yuXZnIgHsvZDO5+HPgG2QhKgXlG L+a+LaoS XJc5lGDUGvQBi4bTgIkf5SIxLSGUk5+pzFJa/caLaQBq3zNwMvbuGXeXvZCKHMUpkIefEf1pJSPdz4+Naxwo+diBwKp/ChUw4IzEZWkOnSYzZdY+/Wv+vO5avkQJpzLsYcKzYQN9iLCfMr7jJ0foz9h/LwIut77aVF8fZchdBj87Z9GwsQ5Qb+R0JAmPIJefrkFnnF91r8vri13iO27MIt5WG7p3HoV4pjqLJJz8h89K914cd8bu0Vfu/o0T4czX+oBpqjfD8vAksNJw= 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 Thu, Jun 26, 2025 at 07:18:59AM -0700, Dave Hansen wrote: > On 6/26/25 06:49, Peter Zijlstra wrote: > >> +static __always_inline void lass_enable_enforcement(void) > >> +{ > >> + alternative("", "clac", X86_FEATURE_LASS); > >> +} > >> + > >> +static __always_inline void lass_disable_enforcement(void) > >> +{ > >> + alternative("", "stac", X86_FEATURE_LASS); > >> +} > > Much hate for this naming. WTH was wrong with lass_{clac,stac}()? > > > > We're not calling those other functions smap_{en,dis}able_enforcement() > > either (and please don't take that as a suggestion, its terrible > > naming). > > It was a response to a comment from Sohil about the delta between > lass_{cl,st}ac() and plain {cl,st}ac() being subtle. They are subtle, > but I don't think it's fixable with naming. > > There are lots of crazy gymnastics we could do. But there are so few > sites where AC is twiddled for LASS that I don't think it's worth it. > > Let's just use the lass_{cl,st}ac() and comment both variants. First, > the existing stac()/clac(): > > /* > * Use these when accessing userspace (_PAGE_USER) > * mappings, regardless of location. > */ > > and the new ones: > > /* > * Use these when accessing kernel mappings (!_PAGE_USER) > * in the lower half of the address space. > */ > > Any objections to doing that? Looks good. Will update the patch. -- Kiryl Shutsemau / Kirill A. Shutemov