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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1F0FC433EF for ; Wed, 29 Sep 2021 00:26:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9F3E0613BD for ; Wed, 29 Sep 2021 00:26:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243420AbhI2A2R convert rfc822-to-8bit (ORCPT ); Tue, 28 Sep 2021 20:28:17 -0400 Received: from mga11.intel.com ([192.55.52.93]:46963 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240715AbhI2A2Q (ORCPT ); Tue, 28 Sep 2021 20:28:16 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10121"; a="221626916" X-IronPort-AV: E=Sophos;i="5.85,330,1624345200"; d="scan'208";a="221626916" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2021 17:26:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,330,1624345200"; d="scan'208";a="476472221" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by orsmga007.jf.intel.com with ESMTP; 28 Sep 2021 17:26:35 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 28 Sep 2021 17:26:35 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 28 Sep 2021 17:26:34 -0700 Received: from orsmsx611.amr.corp.intel.com ([10.22.229.24]) by ORSMSX611.amr.corp.intel.com ([10.22.229.24]) with mapi id 15.01.2242.012; Tue, 28 Sep 2021 17:26:34 -0700 From: "Yu, Fenghua" To: "Luck, Tony" CC: "Hansen, Dave" , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "Peter Zijlstra (Intel)" , Lu Baolu , Joerg Roedel , Josh Poimboeuf , "Jiang, Dave" , "Pan, Jacob jun" , "Raj, Ashok" , "Shankar, Ravi V" , "iommu@lists.linux-foundation.org" , "the arch/x86 maintainers" , Linux Kernel Mailing List Subject: RE: [PATCH 4/8] x86/traps: Demand-populate PASID MSR via #GP Thread-Topic: [PATCH 4/8] x86/traps: Demand-populate PASID MSR via #GP Thread-Index: AQHXrlpps8sdI0y1ikyhBinC7AfU6auyuuKAgAYjzwCAAC8cgIABPj0AgAAIFQCAABNJgIAAB6kAgAAlrYD//5XdAIAAeikA//+NsYA= Date: Wed, 29 Sep 2021 00:26:34 +0000 Message-ID: References: <20210920192349.2602141-5-fenghua.yu@intel.com> <1aae375d-3cd4-4ab8-9c64-9e387916e6c0@www.fastmail.com> <035290e6-d914-a113-ea6c-e845d71069cf@intel.com> <3f97b77e-a609-997b-3be7-f44ff7312b0d@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.200.16 x-originating-ip: [10.1.200.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Tony, > void *begin_update_one_xsave_feature(struct task_struct *tsk, > enum xfeature xfeature, bool full) { > struct xregs_state *xsave = &tsk->thread.fpu.state.xsave; > struct xregs_state *xinit = &init_fpstate.xsave; > u64 fmask = 1ull << xfeature; > void *addr; > > BUG_ON(!(xsave->header.xcomp_bv & fmask)); > > fpregs_lock(); I'm afraid we may hit the same locking issue when we send IPI to notify another task to modify its PASID state. Here the API is called to modify another running task's PASID state as well without a right lock. fpregs_lock() is not enough to deal with this, I'm afraid. Quote from Thomas in https://lore.kernel.org/linux-iommu/87mtsd6gr9.ffs@nanos.tec.linutronix.de/ "FPU state of a running task is protected by fregs_lock() which is nothing else than a local_bh_disable(). As BH disabled regions run usually with interrupts enabled the IPI can hit a code section which modifies FPU state and there is absolutely no guarantee that any of the assumptions which are made for the IPI case is true." Maybe restrict the API's scope: don't modify another task's FPU state, just the current task's state? > addr = __raw_xsave_addr(xsave, xfeature); > > if (full || tsk != current) { > memcpy(addr, __raw_xsave_addr(xinit, xfeature), > xstate_sizes[xfeature]); > goto out; > } > > if (!(xsave->header.xfeatures & fmask)) { > xsave->header.xfeatures |= fmask; //<<<<< > xsaves(xsave, fmask); > } > > out: > xsave->header.xfeatures |= fmask; > return addr; > } > > void finish_update_one_xsave_feature(struct task_struct *tsk) { > set_ti_thread_flag(task_thread_info(tsk), TIF_NEED_FPU_LOAD); > if (tsk == current) //<<<<< > __cpu_invalidate_fpregs_state(); //<<<<< > fpregs_unlock(); > } Thanks. -Fenghua