Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp164517pxb; Tue, 28 Sep 2021 18:20:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwXCD4LEVwc3AjLY0ZpAD431lSsvgOW/khJepcHch8sB+xJ9Lts774PXffvb4BU5lgXWV7a X-Received: by 2002:aa7:c905:: with SMTP id b5mr11825883edt.380.1632878426560; Tue, 28 Sep 2021 18:20:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632878426; cv=none; d=google.com; s=arc-20160816; b=bLJr5kqPCevx988N0x1bzMuBUew30IpXTxw0Qs9tfDJLDK9cF0LfAnml72UDrPpHNY wep0Y6fAKKJYU0dviooc5291yKxd745LIsnWA3byqFfDmjqCbj8OAHaXTEkTEJ1zuMZ3 D4oOaDsl34//xa/91AzC0sALtZccbk1Oa94lGxhbyHDZ6UPCW2M8vSEL8MUZTM1IkjRX Gfc6hyqUhBAjXsKNyMLLnCTSTU1gGM8fie3PbVgT5AiBqgbB+2+DCbSlWHDoHEWF05Rb SVfiEXSUCv5lb2Ys2ShSAUimKmcUpybF4bKjkZjT/4RoVkEbs/k07dvKiJtIMB1Ta3hy Lc2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=4sUfLjYZRjvxxigrGCZGA9pcDjZE4Q9WNmvFRFXb7TU=; b=rd99+VqSoG6T0DOdU30JPaMJTToka4hF3reSit0/T3G2KzN3pb7CbWqg9WnV1frl4M OcEhWrG4zSECKuKt7PzmYwKuZWS3ZsYJo24dnhHDM4M+65S0GnTnoPTgVnpfb/Xghz5H dTmotC4ALoOyUXLoZ5gWdvS+1yddZfOlB6fCxij54mfXSi1sdEUZPRd563I6umbmn6Qy KhnbTbaKkIhS09p8pydww/+i2ByWnxF5bu/lG6SVBMsVchLCnjqeFPWNdQYi2ULp3PLs 0PBMlZIIWECRvJK3pdbqON4YKPUUOw3aTIloWhy6PdlSWc4TMLBaU751Eq3zOAdOMoP/ Rsug== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e8si898306edj.359.2021.09.28.18.20.02; Tue, 28 Sep 2021 18:20:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243574AbhI2BRw (ORCPT + 99 others); Tue, 28 Sep 2021 21:17:52 -0400 Received: from mga11.intel.com ([192.55.52.93]:50798 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242636AbhI2BRt (ORCPT ); Tue, 28 Sep 2021 21:17:49 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10121"; a="221632191" X-IronPort-AV: E=Sophos;i="5.85,330,1624345200"; d="scan'208";a="221632191" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2021 18:16:09 -0700 X-IronPort-AV: E=Sophos;i="5.85,330,1624345200"; d="scan'208";a="562791541" Received: from otcwcpicx3.sc.intel.com ([172.25.55.73]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2021 18:16:09 -0700 Date: Wed, 29 Sep 2021 01:16:08 +0000 From: Fenghua Yu 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 Message-ID: References: <035290e6-d914-a113-ea6c-e845d71069cf@intel.com> <3f97b77e-a609-997b-3be7-f44ff7312b0d@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Tony, On Tue, Sep 28, 2021 at 06:06:52PM -0700, Luck, Tony wrote: > >> 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. > > We don't send IPI any more to change PASID state. The only place that the > current patch series touches the PASID MSR is in the #GP fault handler. It's safe for the helpers to handle the PASID case (modifying the current task's PASID state in #GP). But the helpers seem to be generic. They take "task" as a parameter and handle the task as non-current case. So the helpers are not for PASID only. They may be used by others to modify a running task's FPU state. But It's not safe to do so. At least need some comments/restriction for the helpers to be used on a running task? Thanks. -Fenghua