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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 897E9C433F5 for ; Fri, 18 Feb 2022 20:54:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239575AbiBRUyd (ORCPT ); Fri, 18 Feb 2022 15:54:33 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:59818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233019AbiBRUyb (ORCPT ); Fri, 18 Feb 2022 15:54:31 -0500 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B3E1FDFB0 for ; Fri, 18 Feb 2022 12:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645217654; x=1676753654; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=gqs9pgYk8IAWf5YLT2+4r7t94OiRCL9q78qgGVoC8OM=; b=TZPLSKDC/NzFTNXDZOIhC6kK+9fSEEg6QoDoXc4MvwkeCdgnR1+BrHFH 3L0PWcrXs8rK0S/jxKIpPe8NbwcaniMpGFs82nLWatuYgvPCgEKE6dPWb YX7hNE5cMgpIoBzJAHsZvubvtBIATyybist/CwhnGeHN5Oi77mg7QrsY6 AZTpDtHLyi/PxH/QQlcPriBlIaxpsDKsv4c0GakSgJ7pcvfZs4B85gYCF dgisq6Pd4FZ57aYXffCComClQ4EduRW5BzdlRABxVhGpMjDumAg7e8S6e oqkHvf3jfpZ35BnrRWwdyRV+/wycES6zmjRmnOD2lqrfxEDE2XrlGn9p7 g==; X-IronPort-AV: E=McAfee;i="6200,9189,10262"; a="314484332" X-IronPort-AV: E=Sophos;i="5.88,379,1635231600"; d="scan'208";a="314484332" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2022 12:54:13 -0800 X-IronPort-AV: E=Sophos;i="5.88,379,1635231600"; d="scan'208";a="775387524" Received: from cjjohn4x-mobl1.amr.corp.intel.com (HELO localhost) ([10.212.212.214]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2022 12:54:11 -0800 Date: Fri, 18 Feb 2022 12:54:11 -0800 From: Ira Weiny To: Dave Hansen Cc: "Edgecombe, Rick P" , "hpa@zytor.com" , "Williams, Dan J" , "linux-kernel@vger.kernel.org" , "Yu, Fenghua" , "dave.hansen@linux.intel.com" Subject: Re: [PATCH V8 26/44] x86/fault: Print PKS MSR on fault Message-ID: References: <20220127175505.851391-1-ira.weiny@intel.com> <20220127175505.851391-27-ira.weiny@intel.com> <2a919d9ed8ed874f8b89014c0b42cbadb44d837b.camel@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 On Fri, Feb 18, 2022 at 12:20:58PM -0800, Dave Hansen wrote: > On 2/18/22 09:28, Edgecombe, Rick P wrote: > > On Thu, 2022-02-17 at 22:01 -0800, Ira Weiny wrote: > >> Are you suggesting the PKRU should be printed instead or in addition > >> to the > >> PKS? > > Well I was just thinking that PKRS should only be printed if it's an > > access via a supervisor pte. > > That's not *wrong* per se, but it's not what we do for PKU: > > if (cpu_feature_enabled(X86_FEATURE_OSPKE)) > printk("%sPKRU: %08x\n", log_lvl, read_pkru()); > > If the feature is enabled, we print the register. We don't try to be > fancy and decide if it's relevant to the oops. Why don't you just stick > PKRS on the same line as PKRU whenever it's supported? Ah good point. I'll do that. Thanks, Ira