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 A5173C54E60 for ; Tue, 12 Mar 2024 12:24:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 021316B024A; Tue, 12 Mar 2024 08:24:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F13668D0036; Tue, 12 Mar 2024 08:24:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB4126B024C; Tue, 12 Mar 2024 08:24:28 -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 C93276B024A for ; Tue, 12 Mar 2024 08:24:28 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 77CB7A06E5 for ; Tue, 12 Mar 2024 12:24:28 +0000 (UTC) X-FDA: 81888305016.21.493DD7E Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by imf13.hostedemail.com (Postfix) with ESMTP id 249FC20011 for ; Tue, 12 Mar 2024 12:24:25 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=azv0nz66; spf=none (imf13.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.15) 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=1710246266; a=rsa-sha256; cv=none; b=s+tCjEpPlS+DeAnpUxmGMFOri7v17B39w8jya0x+bv85odBZSdqe5ZQklaU7mgHrE5DrVB QzpdiSGGJggqEwZCS35K5zoM26qal4K9UFNX5ILz8Yo580bv6NoLCXcbVRSNz98He5xEsS 8jkWutvzJ5/9ML1bBfgA+EXFmenycZ0= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=azv0nz66; spf=none (imf13.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.15) 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=1710246266; 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=//dg/a39IwEQQTWM0OIGvwuJG5uhmkV3B0hdooJ3AQM=; b=wkpKp+/ZI1Lbx+Tz6Jubbyy0IgK8WdSlb5wmJLCKe+v4NwvwsawKWhtAeY7dPvMC1bLRx+ Slt3x/LPkNzA/XfkyJOQJ4CgJjcwEKBdL5L9FvwmN3k33avU7hN9rmBXoqxh/r/uu4UHO4 E0dOVa6oDQ+WmOJBqGCBaV+iTQlo3Hk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1710246267; x=1741782267; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Qp3RGcHrPVBEDvQui/FKPyzLuwwwRCqsPvPUZhw6WJY=; b=azv0nz667Nt/LJrbR/7DNzsZqWj2iEQjAY9QXFQGcBwOr16qbKCnkIu8 nJqULR4XGuyQFHzTwG6o4fGZmof+sjYNSmhtcQmtQCOMUtFEcGnqOYvxj 6eVNjhmAZhR99M5RHmzbqXI49fupjRSi2uSS1PzPuDvVeLj+CCH1nUEg4 6x+FyXyHSnE5M8wehYXufV+XQr0EuFjDdyn4x/PQd1oojO3YrKj26U660 710JwisuKG9pqVTXyoS9ifFvVbl5dMnF+kNwn06qhvGvcfHyO1hJu1BTd lEjY42CqQKBW0TgbaFXq/U2xgW85zRjf/Z2lJabQ70A6nEJxdBrUgpfMM A==; X-IronPort-AV: E=McAfee;i="6600,9927,11010"; a="8768896" X-IronPort-AV: E=Sophos;i="6.07,119,1708416000"; d="scan'208";a="8768896" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2024 05:24:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,11010"; a="937051753" X-IronPort-AV: E=Sophos;i="6.07,119,1708416000"; d="scan'208";a="937051753" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga001.fm.intel.com with ESMTP; 12 Mar 2024 05:24:21 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 078A327D; Tue, 12 Mar 2024 14:24:19 +0200 (EET) Date: Tue, 12 Mar 2024 14:24:19 +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 1/3] x86/mm: Use IPIs to synchronize LAM enablement Message-ID: References: <20240312035951.3535980-1-yosryahmed@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240312035951.3535980-1-yosryahmed@google.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 249FC20011 X-Stat-Signature: qncycqpo5yi9zx51zp5cew5r7n6xhdut X-Rspam-User: X-HE-Tag: 1710246265-709522 X-HE-Meta: U2FsdGVkX1+NDn7vmgVKgWPe9sBT0T+h0K0AMHu8rjAAW53x4kN8YtrMhUZCzjwGqasOENeVvImoHm/mblWQXUVl42rvEw9LTpfjMMSE2A3cA1e0cy36Fiy64r65SQYHzvH9vy6BwJdmXg0OXvEEZLHHtK7kQGVTUXwrKmaFGMB8PQxX9Q+IH7l/OM3eACEquy+MQEbCDl00inv/oGg5Mm+RXNRTRiBzEkvQtiSWQZs/SghWn8F6S2OtzC5Xn+JOR5Au+KGYhifr2BIICuczAuumDEaJJWhp/33ZOm8QVZDffwfP9kaDqoPsLDopOhszVFuzgclodjKC81uSE5tkrmvasvtIYfOCJNmwKlPhlyWWsYfEV5MEybeA/vQOp5xGh6qlFhQbIi9N0x3UWtqnasNipaT/f7r+NpqTrtEcxuLIxK5na80p41uDCCFiqtBBMKF8zIivhNdm7t0UgmWmsI5BnYl1BRxpbBKzhfg8SsT2Hf0J2Cg/vN+I4zmRHQPlzVItC8HYitNADZ2/hmgbBzHQVozcPwZSgO2shi+8sQYYM+GVvdXdA5dYKQJVTFF9SSt121qIyO6CQ2HtrVHrB0tQ5ZynP+YDRfykF3aoHcSqh6KYxvdkm090P+C0WaBH9xxuPd36vVmIBCidQLkuUTnZiH8Ti6+OK4xeU+f8+hQfawnOeKhp30beaHY7a/0Jf1oBiDNW33X5VVr/TEjyxTgL/OiXb5G0iOpl9PQiKgsUMtMDlYhfK+uaIMzceekfR9rZxK0VNJG+Z4vVw5hmttFyYfUmyyHWt49bN4y/yBLe9wPbKNUqghUJc4A+I+n0scyuvxURRY4= 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:59:49AM +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. > > If LAM is enabled by a userspace process while a kthread is using its > mm, the kthread will not observe LAM enablement (i.e. LAM will be > disabled in CR3). This could be fine for the kthread itself, as LAM only > affects userspace addresses. However, if the kthread context switches to > a thread in the same userspace process, CR3 may or may not be updated > because the mm_struct doesn't change (based on pending TLB flushes). If > CR3 is not updated, the userspace thread will run incorrectly with LAM > disabled, which may cause page faults when using tagged addresses. > Example scenario: > > CPU 1 CPU 2 > /* kthread */ > kthread_use_mm() > /* user thread */ > prctl_enable_tagged_addr() > /* LAM enabled on CPU 2 */ > /* LAM disabled on CPU 1 */ > context_switch() /* to CPU 1 */ > /* Switching to user thread */ > switch_mm_irqs_off() > /* CR3 not updated */ > /* LAM is still disabled on CPU 1 */ > > Synchronize LAM enablement by sending an IPI from > prctl_enable_tagged_addr() to all CPUs running with the mm_struct to > enable LAM. This makes sure LAM is enabled on CPU 1 in the above > scenario before prctl_enable_tagged_addr() returns and userspace starts > using tagged addresses, and before it's possible to run the userspace > process on CPU 1. > > In switch_mm_irqs_off(), move reading the LAM mask until after > mm_cpumask() is updated. This ensures that if an outdated LAM mask is > written to CR3, an IPI is received to update it right after IRQs are > re-enabled. > > Fixes: 82721d8b25d7 ("x86/mm: Handle LAM on context switch") > Suggested-by: Andy Lutomirski > Signed-off-by: Yosry Ahmed Reviewed-by: Kirill A. Shutemov -- Kiryl Shutsemau / Kirill A. Shutemov