Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2211166ybl; Thu, 29 Aug 2019 05:16:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqyvki/YJj3mmRIUe654CkKQF5tB8I2f36W1Vj7NmcWdEllZuPcCAOjHeccwqeInhxj6noOJ X-Received: by 2002:a65:4546:: with SMTP id x6mr7896947pgr.266.1567080998158; Thu, 29 Aug 2019 05:16:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567080998; cv=none; d=google.com; s=arc-20160816; b=t2SGb4BOjdeDHkxmfUdsQX9G7HObiPerVMILYfrzSiBFE/KL05eGQpZsqOO6ab7nGS aXw9l3+Gx47kDrYA8+HrAuXtFAimkWbkNRjWrJhIGjaBOIAC9dyooMIA5P9gktdCIHnf yU47ZpD+T+zLpUburL3W/t8KWEmdoKQipRZ4A3zfRcy8ZS9WVKnQOwSlQqir0swaOSQC Q5BWEIkDx5bV7WtzrZhN8quU6sulvM6ZlUbMNoWkjrsjT6Z7fFG1iN/E2i7i8VoJU7zw o3ZAcbA8rmNTRRif9xhrD4jbrOROOMpAUmW4WeW3QN6dU5/86QAgAX07FkG3fkBZnPqi yg4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=rqObgHLiroiRS/kBAq7lgveLbxyCYt1AkPl8FUBBRYg=; b=qatBaCEm45nScwVLfbOzCG+loWr9YYWVJbFMO4Xsws+cAvlTkSjFI02ZL0CmvrBWEw o61g9Hctf5E+XLkDlSZM5xFnp0lYr4nX5WprP+o/wEb0VzbW6BOpAQKnIwIV69R5BuI3 NaXsECGBUsNs9ztsI3Sen7YyrBlNjyp4PgoaBRji57m0Snb9K+orR++kx2K4NuTncSCs Acsu/yoCg+my7Gr5S0PDwzMFR+4E28uXCM5ihrX4SWv7hmhIxqyyxM8lPrsj5wHRbezu wPZ4YIErHCe/b7ooF0ayLjddAuciB7u0pkWTjT5yj7yckTTqARoCnl5iD9iwDIfpiUdX ACjg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t25si1820817pgl.7.2019.08.29.05.16.08; Thu, 29 Aug 2019 05:16:38 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727691AbfH2MOo (ORCPT + 99 others); Thu, 29 Aug 2019 08:14:44 -0400 Received: from ozlabs.org ([203.11.71.1]:37313 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727171AbfH2MOn (ORCPT ); Thu, 29 Aug 2019 08:14:43 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 46K1kn0WSMz9sML; Thu, 29 Aug 2019 22:14:41 +1000 (AEST) From: Michael Ellerman To: Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] powerpc/mm: tell if a bad page fault on data is read or write. In-Reply-To: <4f88d7e6fda53b5f80a71040ab400242f6c8cb93.1566400889.git.christophe.leroy@c-s.fr> References: <4f88d7e6fda53b5f80a71040ab400242f6c8cb93.1566400889.git.christophe.leroy@c-s.fr> Date: Thu, 29 Aug 2019 22:14:38 +1000 Message-ID: <87o908tbgx.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christophe Leroy writes: > DSISR has a bit to tell if the fault is due to a read or a write. Except some CPUs don't have a DSISR? Which is why we have page_fault_is_write() that's used in __do_page_fault(). Or is that old cruft? I see eg. in head_40x.S we pass r5=0 for error code, and we don't set regs->dsisr anywhere AFAICS. So it might just contain some junk. cheers > diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c > index 8432c281de92..b5047f9b5dec 100644 > --- a/arch/powerpc/mm/fault.c > +++ b/arch/powerpc/mm/fault.c > @@ -645,6 +645,7 @@ NOKPROBE_SYMBOL(do_page_fault); > void bad_page_fault(struct pt_regs *regs, unsigned long address, int sig) > { > const struct exception_table_entry *entry; > + int is_write = page_fault_is_write(regs->dsisr); > > /* Are we prepared to handle this fault? */ > if ((entry = search_exception_tables(regs->nip)) != NULL) { > @@ -658,9 +659,10 @@ void bad_page_fault(struct pt_regs *regs, unsigned long address, int sig) > case 0x300: > case 0x380: > case 0xe00: > - pr_alert("BUG: %s at 0x%08lx\n", > + pr_alert("BUG: %s on %s at 0x%08lx\n", > regs->dar < PAGE_SIZE ? "Kernel NULL pointer dereference" : > - "Unable to handle kernel data access", regs->dar); > + "Unable to handle kernel data access", > + is_write ? "write" : "read", regs->dar); > break; > case 0x400: > case 0x480: > -- > 2.13.3