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 BB364C54E49 for ; Thu, 7 Mar 2024 17:29:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D72B6B020A; Thu, 7 Mar 2024 12:29:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 25F5F6B020B; Thu, 7 Mar 2024 12:29:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 152236B020C; Thu, 7 Mar 2024 12:29:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id F14326B020A for ; Thu, 7 Mar 2024 12:29:48 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C9009A11EB for ; Thu, 7 Mar 2024 17:29:48 +0000 (UTC) X-FDA: 81870930456.23.1BAEBA9 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by imf02.hostedemail.com (Postfix) with ESMTP id 5CC768002A for ; Thu, 7 Mar 2024 17:29:46 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=cC8swlN+; spf=none (imf02.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.9) 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=1709832586; 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=eTmkaXARmo3N/Mp8/PXvdx9u+PgbpwI3E1dTV/vZEeY=; b=fDnS6MxrBzEuskD8H8W1m0z1m1m0q13P4LCAonZYW6fkKCV4gtI/Fq20ySc5a/c2EVv4hk TDtr1cRRLrjg3VgKB4XI1h6egkZRkGxd9EOmOYobj+b14ngIyeswGN7VgLRCyhswAsnAA1 uTq40LO3moDiyqR2fbiiuc9iv7cmUyw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709832586; a=rsa-sha256; cv=none; b=v+ACUMA7zDY71CImxte5AP3SvHAatvAh1oxS67sle0/beKYLE74alvgMT0RVJTfMAeMD7w g1e+3RM0QvTkfvFYil39XCIQC5xIWMlk9aTq2GHD34+brElgXCIvTlbVxH3QomyVx8ytjI CTPl6I5jlKLGP3Kb/TkHa89VFydpU6c= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=cC8swlN+; spf=none (imf02.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.9) 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=1709832586; x=1741368586; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=uxUbV0oMd2fQbX5ovQlDJR2DtR8unKq0norIZwYBo1s=; b=cC8swlN+BlH0YVbedV9HTT1pG+fqbnYjrADIapyzEXKdIKYnu3jdW0Lh T7qEj0W24r7R6vpmmVnu2jzg9wP5WzLZmhl4q1E21Q8js4v+oSroLOlBk V+BsBjHbTE/+pIDoLgyLOshutlZbBrB9ykn/BuJDKyy3gfERGfFoh0Ulb Es9VAibEn1Qp6qrhJl4Vxf8o0j6TsJ2inhZuWPqyw+9xXEVYmwh/62nOE KnDWJuLU72rPrb6LafoaNQ2w6viIItls1hBZ3uJCsV1G9ApaIpNSkU5NQ nDOFlRonCbnfOlLaw4QBH434s8vypZGYJ32ZpjIV4pX/Bl7gRKCbmsZn+ w==; X-IronPort-AV: E=McAfee;i="6600,9927,11006"; a="26987008" X-IronPort-AV: E=Sophos;i="6.07,107,1708416000"; d="scan'208";a="26987008" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Mar 2024 09:29:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,11006"; a="937046426" X-IronPort-AV: E=Sophos;i="6.07,107,1708416000"; d="scan'208";a="937046426" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga001.fm.intel.com with ESMTP; 07 Mar 2024 09:29:41 -0800 Received: by black.fi.intel.com (Postfix, from userid 1000) id B9D68128; Thu, 7 Mar 2024 19:29:40 +0200 (EET) Date: Thu, 7 Mar 2024 19:29:40 +0200 From: "Kirill A. Shutemov" To: Yosry Ahmed Cc: Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Peter Zijlstra , Andy Lutomirski , x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 2/3] x86/mm: make sure LAM is up-to-date during context switching Message-ID: References: <20240307133916.3782068-1-yosryahmed@google.com> <20240307133916.3782068-3-yosryahmed@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240307133916.3782068-3-yosryahmed@google.com> X-Rspamd-Queue-Id: 5CC768002A X-Rspam-User: X-Stat-Signature: 77q7wf9dor6xzaufpxu4os8qrgx9yd3a X-Rspamd-Server: rspam03 X-HE-Tag: 1709832586-696510 X-HE-Meta: U2FsdGVkX19NiVsJ0Z01fBH1PU8M4WbHpUryZEF4JMxc/18qkxKCmJzj0iJnIcXUi1BMFq132MSBXyEsZ11PfX/Y3boEKZR79hSMXOgPw534eUDvshFdW0eqpJREA9zcV6ZotTktS3JZjbnStTEJnVg/KONZhK6hJ7tKJjPZnIv/7bmMO0U6vHga0hXABfQR81jmYTrGJn+sERPo7K+G88GkU23dt4VHpaH/BL3PkyrYBJF4jWKk9Pt7OEH/N4WwwTwMEZvKDVQxxZu2PSmHFqOReUiKsaDEuayccZ6TqTuNjoSLQHz8sl7E9hfie+gYrGctjngWnk2u9ge9si7SZkhmB6BUbQrvU407xckyCBnl1a+StCWVfstcwRT27Z5XXkS4gnLyvONP+iaPNqxvP2WBX9E5ZckhID+aSkcEkj/oBjI6/F4UDlAmujPP1N9HCoEOmvqPO+FTGGNCRTjeXP/pHQsn5KE4u9v2+nLcMlKUahJV3mJUtWdPffh35LGu6D1ZSGCsEpT360vBHXY4BdfoRv/Q1dcehm/nSuoW2pSSe5VhvbX/2HLejXLgR3NbBKwmCZU3iENTOX3t1ObaO2AlgzDgHbaojSYrtnjsozsA/BcOk2gQa3J4+RbdLFokv3tyN1cZ7YAaaMsVnpnHFjD6uUCDUjaWes+0nBKrQ78ZbgehIFesOC23YaMwdW6vA+OZ7iiM/Jpa3qyEFWlbhyx0WgezZT4t+uiUDozfruy6FvmrEagyVe0h+T2GZnR9w02Trd4hUhicwlwjmagviQ5Y7psNtc1eSgKR7z9HBAjQHXiu0CaOwjisSwfP6X5C0OibfGGBccj0NISbOCwqDiCEauq01xPNPdO+c/bbcyTDNMXri/Zl54w9icIJo9PzqvF+B3isNmsx/ZfecV4L9LCPBmoFAQvN4elMWcLEf0cHeCRiZGVygtY3+v2EbrxPG/pQmONNCSGYG8CFQ7o 5wwaCnpl EG8h+LN4qVmWXTYnoBbB+KU8TtqQaRC/uSJEXPY+qYYT5Q4sIjsPNE2+Sg0wTITSkEr1rUqND30nkw9ZSZwmerZ7c/wEor6UcWMV5eX8ZDID3LvQDightXakUdwMtpwu+W4tH 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, Mar 07, 2024 at 01:39:15PM +0000, Yosry Ahmed wrote: > During context switching, if we are not switching to new mm and no TLB > flush is needed, we do not write CR3. However, it is possible that a > user thread enables LAM while a kthread is running on a different CPU > with the old LAM CR3 mask. If the kthread context switches into any > thread of that user process, it may not write CR3 with the new LAM mask, > which would cause the user thread to run with a misconfigured CR3 that > disables LAM on the CPU. I don't think it is possible. As I said we can only enable LAM when the process has single thread. If it enables LAM concurrently with kernel thread and kernel thread gets control on the same CPU after the userspace thread of the same process LAM is already going to be enabled. No need in special handling. -- Kiryl Shutsemau / Kirill A. Shutemov