Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2531812imu; Mon, 17 Dec 2018 03:40:22 -0800 (PST) X-Google-Smtp-Source: AFSGD/VQZ06O4Z61rUNp6RqnGDRUCv8OU5E8r5874ZQ8k8Mvf2h3+Q9B0tfOWVVATbV5yG+45TTO X-Received: by 2002:a62:5716:: with SMTP id l22mr12929612pfb.16.1545046822742; Mon, 17 Dec 2018 03:40:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545046822; cv=none; d=google.com; s=arc-20160816; b=fi9y2jEGuZhZoEN4Cj7qap1xe34vpR0Oj3LiYNzHSEQPOIQneEUqEm3HK4az6SSkzk rf9QSn4F9/sbRl7MSNdFTxx/KCjkw5M7A1uqL9QXDUVVFEtotBIJ6M59MLZMN/Er+SEP xDQnYn4iwwNNETHGY7v2OsZLlayJXgNrfgpaWLd8XmF1yY097oDUeY+xY/KJfj+Dil9Y KwqAcD3gY30W/botCxDwnlPVD3v920NhusJnnbuzRRoB1enxS1xXPfljwMCtQ2XORKDh nlyQCuzLRGD5mF2K1i2BEx/ZCY0tnBDfNfmxnGvZr6BqMK7Ep3Y2qpE20bOjqrwGADku 2SHg== 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 :message-id:date:references:in-reply-to:subject:cc:to:from; bh=LU5q2SO7JzebuRBhwSWxVkdjtq/kKM584zqXPiZyiyA=; b=d4UC9vN+KEZg2XZ/WaokTHcRr9UXicYIa7ctBMaokIsux0kW9wsTurekikG5/ic0Pu S4R49jlr1e36fkc3PR1h0sBf9GyToLKcIJvxwKaheDklUWOB/LRRWpK1s45HxU/fI7n+ BbIVRZjw5kZKohLVDAMqAZN6ea3e+V7kmMiDFSoSkAvGQbiYaiKNS2OXwqvtLEGBT+fk BovKf6FLXeq4rx7EqVzJ4heexgt9aEl8yaACCpZmCtColh3LB8DPi8X2+VyXA8rhuu1h yHRJQb9gKDF2rbDGzTlQxjSaJepMFSR7xvLO3V7qtemePeYJKpFe6Bxwd68n0IpANqtg 5JxQ== 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 g83si11476988pfb.278.2018.12.17.03.40.07; Mon, 17 Dec 2018 03:40:22 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732217AbeLQLgu convert rfc822-to-8bit (ORCPT + 99 others); Mon, 17 Dec 2018 06:36:50 -0500 Received: from ozlabs.org ([203.11.71.1]:39931 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726965AbeLQLgu (ORCPT ); Mon, 17 Dec 2018 06:36:50 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 43JJyl4Hyhz9sD4; Mon, 17 Dec 2018 22:36:47 +1100 (AEDT) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au 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: make NULL pointer deferences explicit on bad page faults. In-Reply-To: <276439ce-aad9-e72f-7bc9-c57fb4a59339@c-s.fr> References: <42e7e2e9b74af526523fb5a1451fdb29cfe2687a.1539060806.git.christophe.leroy@c-s.fr> <87zht9udqh.fsf@concordia.ellerman.id.au> <276439ce-aad9-e72f-7bc9-c57fb4a59339@c-s.fr> Date: Mon, 17 Dec 2018 22:36:42 +1100 Message-ID: <87va3stmet.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christophe Leroy writes: > Hi Michael, > > Le 14/12/2018 à 01:57, Michael Ellerman a écrit : >> Hi Christophe, >> >> You know it's the trivial patches that are going to get lots of review >> comments :) > > I'm so happy to get comments. Haha :) >> Christophe Leroy writes: >>> As several other arches including x86, this patch makes it explicit >>> that a bad page fault is a NULL pointer dereference when the fault >>> address is lower than PAGE_SIZE >> >> I'm being pedantic, but it's not necessarily a NULL pointer dereference. >> It might just be a direct access to a low address, eg: >> >> char *p = 0x100; >> *p = 0; >> >> That's not a NULL pointer dereference. >> >> But other arches do print this so I guess it's OK to add, and in most >> cases it will be an actual NULL pointer dereference. >> >> I wonder though if we should use 4096 rather than PAGE_SIZE, given >> that's the actual value other arches are using. We support 256K pages on >> some systems, which is getting quite large. > > Those invalid accesses are catched because the first page is marked non > present or non accessible in the page table, so I thing using PAGE_SIZE > here is valid regardless of the page size. It's not a question of whether we catch the fault it's what we print when we catch it. Most of the time on 64-bit the first few GB of the page tables will be empty, so those will all fault, but we don't call them NULL pointer deferences. So I'm just saying that this is a heuristic, ie. an access close to zero is probably an access at a small offset from a NULL pointer, but it may not be. And so it's kind of arbitrary where we decide to make the cut off point between printing that it's a NULL pointer vs a regularly bad access. Anyway I'm happy to use PAGE_SHIFT for now, if anyone complains we can always change it. >> What about: >> >> BUG: Unable to handle kernel instruction fetch at 0x00000000 > > I think we still need to make it explicit that we jumped there due to a > NULL function pointer, allthought I don't have a good text idea yet for > this. Being pedantic again, we don't know that it was a NULL function pointer. You might have done a bad setcontext and set your NIP to zero. But it's probably fine to print it as a hint, and it's probably right most of the time. cheers