Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp646672pxf; Wed, 31 Mar 2021 12:18:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwwK8jQQDrMy2BEAsvNBHzNOr4FkrRCYsNw2a5eCUrcNJ4ejqhTqjEK24Ntv7YCfEcXZ0Mr X-Received: by 2002:a17:907:75d9:: with SMTP id jl25mr5162269ejc.452.1617218335520; Wed, 31 Mar 2021 12:18:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617218335; cv=none; d=google.com; s=arc-20160816; b=n61hrtecQHiBdMUa9obIY3qpeqM5kY1grCrDJPr+nzEMnWi+URrV1+Iq0zksq+NUqE wlJD3spZcqLy6AJMFlUR5+XQHCbh1hWnKLRQfawglG5/NACsY77r/WYBzO2JnhVSjDVw 8gS4BKF66UzObhlYdbPb/S5LknHjefbWpkUT7Pf3H249KMKp/r+AhgMWewurYgcpvJoV VttdISY9IHmOXYxrYuKa8IJMhm/W+kAfzyBAtc0WNwDQAXwx0vr5wEkw1HOYYUC5WZyN X901heiKShMhVmZVfDtDEQ8gPSJbVupfRhXID+cjo+jeeO5wiDk1pMi2r93FeVyjQusJ 8UiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :ironport-sdr:ironport-sdr; bh=lVqB+/AV+c5kg1ckXRmoRjNV88sIUB+Jz5rO159H60w=; b=RXM24BOLteLpD1wSvF4qtNH5bCxejlIPAawx0JVQdgp1hQur6EIQin6U6ZtafxbvBy GcBCHjB4xK1ZUVIGPcO9KA7770IPUIkKfG5MOti6bhFhk4mR8Kv05XRArHRq+UCD+4tF uQWI/xdnOAWqEkcBXQ78Ni9dmICNw3RhzIAZKv1tMxgDZ7O4CvafWqIYCGQb6qg0NoqP oNzbYt9fNMnytj7Q+NnGuJ8H6nJTRp2+WXvOYpSFNfsycxqWfvakOKeRihY1h5/dpEpa qzw6hXWNHd7RzBwzesodtWaqqEBy+MQxhoRkIcbXD1o2EOAmE+xzG9aKvYllwpoff/6y RBhw== 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 dm14si2445817ejc.502.2021.03.31.12.18.30; Wed, 31 Mar 2021 12:18:55 -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 S236239AbhCaTO4 (ORCPT + 99 others); Wed, 31 Mar 2021 15:14:56 -0400 Received: from mga12.intel.com ([192.55.52.136]:51675 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235205AbhCaTOU (ORCPT ); Wed, 31 Mar 2021 15:14:20 -0400 IronPort-SDR: 13l5yCSUSa49xcacdNew7eFZCleSrAnZbShh12NyS72hi6JW1avhiUPa7J2Oa+2pIxH5UvMNOs YcL9P2ltxjKQ== X-IronPort-AV: E=McAfee;i="6000,8403,9940"; a="171490619" X-IronPort-AV: E=Sophos;i="5.81,293,1610438400"; d="scan'208";a="171490619" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Mar 2021 12:14:20 -0700 IronPort-SDR: JkU84B66zZpAcXI/v04F3IGdywiPXk5XQoo+rWf0jLIWXQfa0+Hnr1yghVpGQvFrmE8roN/Kvd oDas3Iu6ArBQ== X-IronPort-AV: E=Sophos;i="5.81,293,1610438400"; d="scan'208";a="610625404" Received: from iweiny-desk2.sc.intel.com (HELO localhost) ([10.3.52.147]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Mar 2021 12:14:20 -0700 From: ira.weiny@intel.com To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Andy Lutomirski , Peter Zijlstra Cc: Ira Weiny , Sean Christopherson , Dan Williams , Dave Hansen , x86@kernel.org, linux-kernel@vger.kernel.org, Fenghua Yu , linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [PATCH V5 06/10] x86/fault: Adjust WARN_ON for PKey fault Date: Wed, 31 Mar 2021 12:14:01 -0700 Message-Id: <20210331191405.341999-7-ira.weiny@intel.com> X-Mailer: git-send-email 2.28.0.rc0.12.gb6a658bd00c9 In-Reply-To: <20210331191405.341999-1-ira.weiny@intel.com> References: <20210331191405.341999-1-ira.weiny@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ira Weiny Previously if a Protection key fault occurred it indicated something very wrong because user page mappings are not supposed to be in the kernel address space. Now PKey faults may happen on kernel mappings if the feature is enabled. Remove the warning in the fault path and allow the oops to occur without extra debugging if PKS is enabled. Cc: Sean Christopherson Cc: Dan Williams Signed-off-by: Ira Weiny --- Changes from V4: From Sean Christopherson Clean up commit message and comment Change cpu_feature_enabled to be in WARN_ON check --- arch/x86/mm/fault.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index a73347e2cdfc..c32d01803e26 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -1141,11 +1141,15 @@ do_kern_addr_fault(struct pt_regs *regs, unsigned long hw_error_code, unsigned long address) { /* - * Protection keys exceptions only happen on user pages. We - * have no user pages in the kernel portion of the address - * space, so do not expect them here. + * X86_PF_PK (Protection key exceptions) may occur on kernel addresses + * when PKS (PKeys Supervisor) are enabled. + * + * If PKS is not enabled an exception should only happen on user pages. + * Because, we have no user pages in the kernel portion of the address + * space something must have gone very wrong and we should WARN. */ - WARN_ON_ONCE(hw_error_code & X86_PF_PK); + WARN_ON_ONCE(!cpu_feature_enabled(X86_FEATURE_PKS) && + (hw_error_code & X86_PF_PK)); #ifdef CONFIG_X86_32 /* -- 2.28.0.rc0.12.gb6a658bd00c9