Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp971130imu; Fri, 7 Dec 2018 11:53:19 -0800 (PST) X-Google-Smtp-Source: AFSGD/X70UCDAW/R3oM+9NPVkFwgSXqX/mQWGODF3bUjV5PhVfuiECkr1F5dI5XMA25ZEU4zOw0a X-Received: by 2002:a62:75d1:: with SMTP id q200mr3531640pfc.254.1544212399219; Fri, 07 Dec 2018 11:53:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544212399; cv=none; d=google.com; s=arc-20160816; b=vRA47J25nYBNqHZ2u3+Nod1dR5mOdc5E/lQWzE4mdfGQBOi48p8ZhuRpNKBxEPSxNp TOztlriVHIdLLjYppwTEpT9Taf/LfoE2HS6gaHjsP8HoeOhhQXrriFQe0IYoVl4Bnuml scIpt8UwTvXXJS+lyCYmlCXuFsy1bTmzseyFFL/TMVaDz0LIkBjRdZhZLGk6VPPtVfHR JEP1bnR3LmtFbIPFLXjwGq23VbE+Pxzn9tsXSBui+uJNZVIBx5RUIUy1dU6tUA0VBtKl DFOmhIMlNjLKcce3depNnDoVG5ovGjHMVc/NXlOEFkG0gSHezerI5BOHHUwJB7mQiDTC SbCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=SIBJcUohXza3N4X7MGbymvKT1X298ABBDPeb50ekRew=; b=DqTzSpnWeIOEIodSty/amaXagpp9nHGBLLWGJv3PSCeR+Rm6tL6VifGaEEqSvTXRUd zh0Oa9IGnYa0IZUFYN+tpfmvgH4Cp68nfRGiUNIOnzIQc5+ueIEwSChE1WGqR23hpA3u JnZyir+Y7BU7XJ1N88PllgqhcIkjN60E7Giu8WsWr9MW16K6NQHkLN3lmGr/65w2DmGC eZgpZqm2dbW2dgElgO+t210DXAKJmr9ANWgM0N9YYQhhHGoqO6319oAv1aBaVCYXzhb8 lt0k0Gki0SZhUPmYEWlbTG9QnPecvDuSqO7WthCZ/WNHPJoCGtF6aWyK3akRLuXn450B bPvg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id b91si3746031plb.11.2018.12.07.11.53.03; Fri, 07 Dec 2018 11:53:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1726073AbeLGTw2 (ORCPT + 99 others); Fri, 7 Dec 2018 14:52:28 -0500 Received: from mga09.intel.com ([134.134.136.24]:49113 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726041AbeLGTw2 (ORCPT ); Fri, 7 Dec 2018 14:52:28 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2018 11:52:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,327,1539673200"; d="scan'208";a="128065736" Received: from sjchrist-coffee.jf.intel.com ([10.54.74.154]) by fmsmga001.fm.intel.com with ESMTP; 07 Dec 2018 11:52:27 -0800 From: Sean Christopherson To: Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org Cc: "H. Peter Anvin" , linux-kernel@vger.kernel.org, Linus Torvalds , Rik van Riel , Yu-cheng Yu , Ingo Molnar Subject: [PATCH v2] x86/fault: Decode and print #PF oops in human readable form Date: Fri, 7 Dec 2018 11:52:23 -0800 Message-Id: <20181207195223.23968-1-sean.j.christopherson@intel.com> X-Mailer: git-send-email 2.19.2 In-Reply-To: <20181207184423.1962-1-sean.j.christopherson@intel.com> References: <20181207184423.1962-1-sean.j.christopherson@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus pointed out that deciphering the raw #PF error code and printing a more human readable message are two different things, and also that printing the negative cases is mostly just noise[1]. For example, the USER bit doesn't mean the fault originated in user code and stating that an oops wasn't due to a protection keys violation isn't interesting since an oops on a keys violation is a one-in-a-million scenario. Remove the per-bit decoding of the error code and instead print: - the raw error code - why the fault occurred - the effective privilege level of the access - the type of access - whether the fault originated in user code or kernel code This provides the user with the information needed to triage 99.9% of oopses without polluting the log with useless information or conflating the error_code with the CPL. [1] https://lkml.kernel.org/r/CAHk-=whk_fsnxVMvF1T2fFCaP2WrvSybABrLQCWLJyCvHw6NKA@mail.gmail.com Suggested-by: Linus Torvalds Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Dave Hansen Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: Yu-cheng Yu Cc: linux-kernel@vger.kernel.org Cc: Ingo Molnar Signed-off-by: Sean Christopherson --- v2: - Explicitly call out protection keys violations - "Slightly" reword the changelog arch/x86/mm/fault.c | 42 +++++++++++------------------------------- 1 file changed, 11 insertions(+), 31 deletions(-) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index 2ff25ad33233..26feb8c525c1 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -603,24 +603,9 @@ static void show_ldttss(const struct desc_ptr *gdt, const char *name, u16 index) name, index, addr, (desc.limit0 | (desc.limit1 << 16))); } -/* - * This helper function transforms the #PF error_code bits into - * "[PROT] [USER]" type of descriptive, almost human-readable error strings: - */ -static void err_str_append(unsigned long error_code, char *buf, unsigned long mask, const char *txt) -{ - if (error_code & mask) { - if (buf[0]) - strcat(buf, " "); - strcat(buf, txt); - } -} - static void show_fault_oops(struct pt_regs *regs, unsigned long error_code, unsigned long address) { - char err_txt[64]; - if (!oops_may_print()) return; @@ -648,27 +633,22 @@ show_fault_oops(struct pt_regs *regs, unsigned long error_code, unsigned long ad address < PAGE_SIZE ? "NULL pointer dereference" : "paging request", (void *)address); - err_txt[0] = 0; - - /* - * Note: length of these appended strings including the separation space and the - * zero delimiter must fit into err_txt[]. - */ - err_str_append(error_code, err_txt, X86_PF_PROT, "[PROT]" ); - err_str_append(error_code, err_txt, X86_PF_WRITE, "[WRITE]"); - err_str_append(error_code, err_txt, X86_PF_USER, "[USER]" ); - err_str_append(error_code, err_txt, X86_PF_RSVD, "[RSVD]" ); - err_str_append(error_code, err_txt, X86_PF_INSTR, "[INSTR]"); - err_str_append(error_code, err_txt, X86_PF_PK, "[PK]" ); - - pr_alert("#PF error: %s\n", error_code ? err_txt : "[normal kernel read fault]"); + pr_alert("#PF: error_code(0x%04lx) - %s\n", error_code, + !(error_code & X86_PF_PROT) ? "not-present page" : + (error_code & X86_PF_RSVD) ? "reserved bit violation" : + (error_code & X86_PF_PK) ? "protection keys violation" : + "permissions violation"); + pr_alert("#PF: %s-privileged %s from %s code\n", + (error_code & X86_PF_USER) ? "user" : "supervisor", + (error_code & X86_PF_INSTR) ? "instruction fetch" : + (error_code & X86_PF_WRITE) ? "write access" : + "read access", + user_mode(regs) ? "user" : "kernel"); if (!(error_code & X86_PF_USER) && user_mode(regs)) { struct desc_ptr idt, gdt; u16 ldtr, tr; - pr_alert("This was a system access from user code\n"); - /* * This can happen for quite a few reasons. The more obvious * ones are faults accessing the GDT, or LDT. Perhaps -- 2.19.2