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 5BD21C54791 for ; Wed, 13 Mar 2024 13:38:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8637480029; Wed, 13 Mar 2024 09:38:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 81265940010; Wed, 13 Mar 2024 09:38:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7016080029; Wed, 13 Mar 2024 09:38:56 -0400 (EDT) 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 62080940010 for ; Wed, 13 Mar 2024 09:38:56 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id F2BB7A16E3 for ; Wed, 13 Mar 2024 13:38:55 +0000 (UTC) X-FDA: 81892121430.13.B7860F8 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) by imf30.hostedemail.com (Postfix) with ESMTP id A7B4280028 for ; Wed, 13 Mar 2024 13:38:53 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=AuHAU8I9; spf=none (imf30.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.198.163.16) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710337134; a=rsa-sha256; cv=none; b=7izfdCzKb+QHzFXbdk6O5R0sxtFuIAj5PCrs90VGLva20U/o1Qm1gizOeOkg28D1ap8rmp 9icGLKE3ROrwzTesgFKHrqEcQoipaK0iv6Q4AiB+r5XGkCDwdcO0x1VRmNWRg4DNhTdX+t rMYOnhvhGVnNbo/7qL3HOibuwv7Uz+Y= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=AuHAU8I9; spf=none (imf30.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.198.163.16) 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=1710337134; 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=0Z1VbgMrCZDZJdjoAYJr71bb6LFVjJIHEsteH/3CjyM=; b=WsGofeDtBR/sj1ITjOOZxdcb1KDVCQUoBnAcJJwLbRVArH1oX5Sbg7z0t1Nmx2xb0RX6fw VTSRctactN8vRrVXiqAYMAGBqedAeaVOfQVHZAz87u32msrc6KtPbxbXMIYZlf3QkVsw2g m222elVI2DwGD9fpYgGalJM/VkgFVSg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1710337134; x=1741873134; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=BOcy5v8jTDEf4Uwi1cewwmZO/FeGeMFiYXTFAhC4WZk=; b=AuHAU8I9mFPOggQChW+Y4MosPMu2/OKmPZYOsOFxJMqA3qbNLdEe5V/w OG0FFVO2HHMCJwZLXIv7mlsckvajQpj8dmi3LdWe41gOTmaIh6UouhRvh EE1MGbcj2hus/0hFKTlEu2kDrWafD0nHcItspZhvv10W1NVmZuotVHxfx 1hRVgqw7I0wttLvons4bajpSrKxo60wL1uMx6Czpp9oJDwPc1qYE/MHfZ AB8JYVk02PRkXSjxn+SnaW2O9pDebVlFRZNyD9SwNARyjCXOFwhJ67lff UV6Otol3gnuHSXIbb09NcFfAyfqDTREkzawqc7Hptkl8rI1RzcTaY1EUU w==; X-IronPort-AV: E=McAfee;i="6600,9927,11011"; a="5708197" X-IronPort-AV: E=Sophos;i="6.07,122,1708416000"; d="scan'208";a="5708197" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Mar 2024 06:38:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,11011"; a="937054147" X-IronPort-AV: E=Sophos;i="6.07,122,1708416000"; d="scan'208";a="937054147" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga001.fm.intel.com with ESMTP; 13 Mar 2024 06:38:48 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 18FE91057; Wed, 13 Mar 2024 15:38:46 +0200 (EET) Date: Wed, 13 Mar 2024 15:38:46 +0200 From: "Kirill A. Shutemov" To: Yosry Ahmed Cc: x86@kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Rick Edgecombe , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/3] x86/mm: Fix LAM inconsistency during context switch Message-ID: References: <20240312155641.4003683-1-yosryahmed@google.com> <20240312155641.4003683-2-yosryahmed@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240312155641.4003683-2-yosryahmed@google.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: A7B4280028 X-Stat-Signature: pkdt964cmf8t5h5qgzanh9zr8wmtqdos X-Rspam-User: X-HE-Tag: 1710337133-740273 X-HE-Meta: U2FsdGVkX1/8hO7FnEDuU/gX2lF+/9oeJk5DeYIm8IF3CjDvgjeJX4/LyIy263h0Y2/0YidKPvTrXvWGyoec+s/v49f7lWz99aRFAQSGUDIQmJuUZdOPEojbDTkVg8p9V0mGfZFYn+AeXG0lqsLQ/M2zF4xRVLaWTRdOkCPUW43PaqwgyamF/lhycrlkK7dgfSNV74yc7mlhp8UqQhdXQlsAbEkaOfLl3rSpnEzAUrCgYkBMmfjQKLrtx8bJ3TecqnZBBsX/5lX/4PhLqSUxasJbSmTr0TbEDQfGYihjSCJatJ3YSJbMU+Fr6UgcFOp0/QE0ZAFBz2C09rHN6lvTjLhdzrg2jVeEMPc6PI0mHBSjzxnDuyMWJQgBvvigJU4JxBupzE9ep3sIUBkc/gidM7lW+fgmEpEfOScj3BROMY6eG4BqSM+BiJuHAsiEGYQCQki3NyDwlj3M6rXJERqTyuzd7UURSfSH9Jq9LVi+laEVInNQ627tBd5zW0p55boCpVVx9mQ9fNS5YqIiEumAhUGtSR+Np9qHVdHB6sK5gXlgKcCoWAnuIDJagbVytw3OiQpd40KyMmB7+jyrjOl5PukpcIUqg5XB1TLoLBL6OVnQfkbaeyLEXa1AoMyQUQ6Z5TS9RMaEDD1ByuawkLqwAF2WwFXwdMqswwqwJdXFMwAuBuA1c5l5aqcLAh4eUh10uK2MVWG+5+W9a88WYHg5mkBrXe8vM05EYRnLxxBvD0mLGg0/wCpVZOr4+jHwrGH6mvdFYQ/ldTbIWHwTYr3eOik7ssIoHjoy0So0vhJRTkTUXoa2peWBDaa4aoDTCJSCtzvw5ZqFhxk= 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, Mar 12, 2024 at 03:56:40PM +0000, Yosry Ahmed wrote: > LAM can only be enabled when a process is single-threaded. But _kernel_ > threads can temporarily use a single-threaded process's mm. That means > that a context-switching kernel thread can race and observe the mm's LAM > metadata (mm->context.lam_cr3_mask) change. > > The context switch code does two logical things with that metadata: > populate CR3 and populate 'cpu_tlbstate.lam'. If it hits this race, > 'cpu_tlbstate.lam' and CR3 can end up out of sync. > > This de-synchronization is currently harmless. But it is confusing and > might lead to warnings or real bugs. > > Update set_tlbstate_lam_mode() to take in the LAM mask and untag mask > instead of an mm_struct pointer, and while we are at it, rename it to > cpu_tlbstate_update_lam(). This should also make it clearer that we are > updating cpu_tlbstate. In switch_mm_irqs_off(), read the LAM mask once > and use it for both the cpu_tlbstate update and the CR3 update. > > Signed-off-by: Yosry Ahmed Reviewed-by: Kirill A. Shutemov -- Kiryl Shutsemau / Kirill A. Shutemov