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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 99C59C433F5 for ; Mon, 13 Sep 2021 20:01:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 768326108B for ; Mon, 13 Sep 2021 20:01:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347764AbhIMUDN (ORCPT ); Mon, 13 Sep 2021 16:03:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:53498 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347763AbhIMUDJ (ORCPT ); Mon, 13 Sep 2021 16:03:09 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BD1A560E9C; Mon, 13 Sep 2021 20:01:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1631563310; bh=gLNHs6CcvSnX7/miQjZSjEGPQiOP4SA5DpU0CvsJrqk=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=liajztqhepeUtWSNEfNIAqpGCdq5Rx9uhrK7Bt/4aB5DkL2QG/U1cdkUaQgNZFTm1 BEJRMiLsmo/Vp6PKZ3RFSUNE4uq/buNfLnpmGKxAWEuzkXNaGgzJTLsQuNi1NDLQ+U EW0ci2uEGYCEYeTKJK9FnpA0p74lro6O8uRo0B7MGODoFkx+UKKBqv20AeUaZJ5ZB2 RE97+esnfChnY6ovKlEH/sDn9JOF2DdBXIbAgMfLaAG3VUZC+uyv1svJLFPVRUdLoh I7pxT4Chp27Yv3N4qmbDiuWqnx1NabtyGwnSW1Zv16Oyrnw23RV7s5aax45oHyhiNz dB3ISjuJoy0gQ== Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id DFDFC27C0054; Mon, 13 Sep 2021 16:01:48 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Mon, 13 Sep 2021 16:01:48 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudegjedgudegudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehn ugihucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecugg ftrfgrthhtvghrnheptdfhheettddvtedvtedugfeuuefhtddugedvleevleefvdetleff gfefvdekgeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheprghnugihodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiudek heeifedvqddvieefudeiiedtkedqlhhuthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuh igrdhluhhtohdruhhs X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0E6DCA00387; Mon, 13 Sep 2021 16:01:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1229-g7ca81dfce5-fm-20210908.005-g7ca81dfc Mime-Version: 1.0 Message-Id: In-Reply-To: <20210902105052.2842-1-jiangshanlai@gmail.com> References: <20210831175025.27570-1-jiangshanlai@gmail.com> <20210902105052.2842-1-jiangshanlai@gmail.com> Date: Mon, 13 Sep 2021 13:01:25 -0700 From: "Andy Lutomirski" To: "Lai Jiangshan" , "Linux Kernel Mailing List" Cc: "Lai Jiangshan" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "the arch/x86 maintainers" , "H. Peter Anvin" , "Dave Hansen" , "Peter Zijlstra (Intel)" , "Dave Jiang" , "Ben Widawsky" , "Williams, Dan J" , "Arvind Sankar" Subject: Re: [PATCH 25/24] x86/traps: Rewrite native_load_gs_index in C code Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 2, 2021, at 3:50 AM, Lai Jiangshan wrote: > From: Lai Jiangshan > > There is no constrain/limition to force native_load_gs_index() to be in > ASM code. > > Signed-off-by: Lai Jiangshan > > #ifdef CONFIG_X86_64 > + > +/* > + * Reload gs selector with exception handling > + * selector: new selector > + * > + * Is noinstr as it shouldn't be instrumented. > + */ > +noinstr void native_load_gs_index(unsigned int selector) > +{ > + unsigned long flags; > + > + local_irq_save(flags); This patch would be a bit less alarming if you moved the swapgs into asm. Also, this needs a comment explaining why skipping the swapgs back to kernel gs in the exception path is correct. > + native_swapgs(); > + asm volatile( > + ".global asm_load_gs_index_gs_change \n" > + "asm_load_gs_index_gs_change: \n" > + "1: movl %0, %%gs \n" > + " swapgs \n" > + "2: \n" > + _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_clear_gs) > + :: "r" (selector) : "memory"); > + alternative("", "mfence", X86_BUG_SWAPGS_FENCE); > + local_irq_restore(flags); > +} > +