Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp857820pxf; Thu, 1 Apr 2021 16:00:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzZGfmiR5woWqiEarECek2WqB9czJwuLQfcrxLmuWTUfAHCNBKpkSZXnmMFvNyd9BqTRBG1 X-Received: by 2002:a17:906:a2d3:: with SMTP id by19mr11111226ejb.98.1617318029022; Thu, 01 Apr 2021 16:00:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617318029; cv=none; d=google.com; s=arc-20160816; b=nBCXTxDeOw5IjZcy8proB8swH2smbeHq4SIPprUI1tQ22CjesTfYoPdqkzjoB24hX/ ZgSkTahxksNg3pjLXkuPhm8MV8xKhvvXDsCIpXDY7yIzp0bBvR2jF7jkcbKVA3NuXYu2 qThcSqELQ2xQmdpuhuHbzAluDaeHKqsM2EX6K6EI8SUV77pcwU937haNwf7Kb9m22/71 LSwiB2YLeDuUvVenVnlvkh3DgQXZVkpCbzpgkYzw+bnno6ieQcAtDDSQt1jzqRmtx2Je IZq9hy0IJpy95y9KNhtd4QeMwYk68+iSSIwzUm/7X4XOw3iXhiHweUtZIxS+3vbILzr2 zTOg== 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=9CMOQwkJEWAUOd08JOUH/msIqWnabDOeG+dVVk2sOiE=; b=IOH5YEMIZHIVeWapoJHAg1v9SGMgMA1zm+3UcAPfT6cDFeHrTfP8C8fD81i349KJji 0j48k93V2uxITTMyW5/7XeZx3/Q3QMlrViRBn2sxQGigdZrMdoC8bhnMmyJLkreUFOue mR0XSu28I/FvcRYcJjsyj/6ffFPYhqh+eJ9dT2R60uB8y5MIvAy/vpsHLiSygErWPhqh RuTJ7b2Je4wszZxR3s97ZrGBAD/XGR/HxO9fJRhFOSNWFHvgYQHJK+frYqjCTUMfmJRB kGODSFt57xBlnQOb8MZPNM/SfeoAuhosfOeFvfaVmHhohzp9zL30CyMgGuj8FeXNYfuS qy6g== 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 p15si5086101ejr.236.2021.04.01.16.00.05; Thu, 01 Apr 2021 16:00:29 -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 S236041AbhDAW7C (ORCPT + 99 others); Thu, 1 Apr 2021 18:59:02 -0400 Received: from mga04.intel.com ([192.55.52.120]:11530 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235373AbhDAW6i (ORCPT ); Thu, 1 Apr 2021 18:58:38 -0400 IronPort-SDR: dui/g2P/GGrVuqZk2FY7siuSxrKXhN57D6ClSJOiBYJyRdY83+muKkkxoAG4pg8IDieNX72Epl tPxASwsBrIJQ== X-IronPort-AV: E=McAfee;i="6000,8403,9941"; a="190117107" X-IronPort-AV: E=Sophos;i="5.81,296,1610438400"; d="scan'208";a="190117107" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2021 15:58:37 -0700 IronPort-SDR: Iu6fTwQoZ98uMmFHDB6Z8+rKIc+0xugOW7VluQv1j6K3mita2jQ/Fub6hUzbaajpXc3KEAqIyg qCFecINMnZVA== X-IronPort-AV: E=Sophos;i="5.81,296,1610438400"; d="scan'208";a="611092362" 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; 01 Apr 2021 15:58:37 -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 V6 06/10] x86/fault: Adjust WARN_ON for PKey fault Date: Thu, 1 Apr 2021 15:58:29 -0700 Message-Id: <20210401225833.566238-7-ira.weiny@intel.com> X-Mailer: git-send-email 2.28.0.rc0.12.gb6a658bd00c9 In-Reply-To: <20210401225833.566238-1-ira.weiny@intel.com> References: <20210401225833.566238-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 V5: From Dave Hansen Remove 'we' from comment 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..0e0e90968f57 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) is enabled. + * + * However, if PKS is not enabled WARN if this exception is seen + * because there are no user pages in the kernel portion of the address + * space. */ - 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