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 X-Spam-Level: X-Spam-Status: No, score=-16.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C78DCC47094 for ; Thu, 10 Jun 2021 17:11:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A41F9613FE for ; Thu, 10 Jun 2021 17:11:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231148AbhFJRNS (ORCPT ); Thu, 10 Jun 2021 13:13:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:46834 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229802AbhFJRNQ (ORCPT ); Thu, 10 Jun 2021 13:13:16 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9C289613C9; Thu, 10 Jun 2021 17:11:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623345080; bh=5i1YYQPe0SKOHI2nfgnCq6FvKp5HQINwp673ARQ1VXM=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=sZLYDAkzceQzmHC8j1hrcOsy4f5x6gHdtTEbmkpg8MoRNEu9XCYJkIDM2/bHTVeI0 6irbV3NMp/06UEtvUSVSTK4C37F0xD9yI4TL3GN2WPhftgeIgf1IZNE760YDpU/tkD hjBHLXWtWh3dKTUuVs0YLqGNn0zKd8ERO94g1G9axxNSKBuQGy34iT4FsPI6bd2w7a IpaMZ9zVMo86HXa4YNBCeGlUMD8CtcipbYvNAHAjqZpH/hlsBocU1fOlet7VKvhUnt OR574b3hy7Z2HH49kw3x+E+4legwFjHGX2/YDjT6JqMwXEb0sGjbiOtzQPGQ5XLVpp tgFL4F+4rCN7w== Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailauth.nyi.internal (Postfix) with ESMTP id A622027C005A; Thu, 10 Jun 2021 13:11:18 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute2.internal (MEProxy); Thu, 10 Jun 2021 13:11:18 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedufedguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdet nhguhicunfhuthhomhhirhhskhhifdcuoehluhhtoheskhgvrhhnvghlrdhorhhgqeenuc ggtffrrghtthgvrhhnpedvleehjeejvefhuddtgeegffdtjedtffegveethedvgfejieev ieeufeevuedvteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegrnhguhidomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduiedu keehieefvddqvdeifeduieeitdekqdhluhhtoheppehkvghrnhgvlhdrohhrgheslhhinh hugidrlhhuthhordhush X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8673251C0060; Thu, 10 Jun 2021 13:11:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-519-g27a961944e-fm-20210531.001-g27a96194 Mime-Version: 1.0 Message-Id: In-Reply-To: <20210608144345.912645927@linutronix.de> References: <20210608143617.565868844@linutronix.de> <20210608144345.912645927@linutronix.de> Date: Thu, 10 Jun 2021 10:10:51 -0700 From: "Andy Lutomirski" To: "Thomas Gleixner" , "Linux Kernel Mailing List" Cc: "the arch/x86 maintainers" , "Dave Hansen" , "Fenghua Yu" , "Tony Luck" , "Yu-cheng Yu" , "Sebastian Andrzej Siewior" , "Rik van Riel" , "Borislav Petkov" Subject: =?UTF-8?Q?Re:_[patch_V3_3/6]_x86/process:_Check_PF=5FKTHREAD_and_not_cur?= =?UTF-8?Q?rent->mm_for_kernel_threads?= Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 8, 2021, at 7:36 AM, Thomas Gleixner wrote: > switch_fpu_finish() checks current->mm as indicator for kernel threads= . > That's wrong because kernel threads can temporarily use a mm of a user= > process via kthread_use_mm(). >=20 > Check the task flags for PF_KTHREAD instead. >=20 > Fixes: 0cecca9d03c9 ("x86/fpu: Eager switch PKRU state") > Signed-off-by: Thomas Gleixner > Cc: Rik van Riel > Cc: stable@vger.kernel.org > --- > arch/x86/include/asm/fpu/internal.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > --- a/arch/x86/include/asm/fpu/internal.h > +++ b/arch/x86/include/asm/fpu/internal.h > @@ -578,7 +578,7 @@ static inline void switch_fpu_finish(str > * PKRU state is switched eagerly because it needs to be valid befor= e we > * return to userland e.g. for a copy_to_user() operation. > */ > - if (current->mm) { > + if (!(current->flags & PF_KTHREAD)) { > pk =3D get_xsave_addr(&new_fpu->state.xsave, XFEATURE_PKRU); > if (pk) > pkru_val =3D pk->pkru; >=20 >=20 Why are we checking this at all? I actually tend to agree with the ->mm= check more than PF_anything. If we have a user address space, then PKRU= matters. If we don=E2=80=99t, then it doesn=E2=80=99t.