From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 2B82BB7B94 for ; Tue, 6 Oct 2009 17:44:55 +1100 (EST) Subject: Re: [PATCH 0/6] PowerPc 8xx TLB/MMU fixes From: Benjamin Herrenschmidt To: Joakim Tjernlund In-Reply-To: References: <1254744999-3158-1-git-send-email-Joakim.Tjernlund@transmode.se> <20091005220420.GA27923@compile2.chatsunix.int.mrv.com> <20091005224218.GA5273@compile2.chatsunix.int.mrv.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 06 Oct 2009 17:44:46 +1100 Message-Id: <1254811486.6035.2.camel@pasglop> Mime-Version: 1.0 Cc: Scott Wood , "linuxppc-dev@ozlabs.org" , Rex Feany List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > > I assumed it was NIP because ... I'm not sure why. TRAP() above > > dereferences regs, and that didn't fail, but I didn't see that until > > now. > > Yes, it is a bit strange though that the kernel isn't allowed to read from > NULL. Is that expected? Yes, that's absolutely expected :-) You really want any NULL deref to blow up asap. 0 is actually part of the address space assigned to user processes. By default they don't have anything there neither though, but if the current process do have something mapped there, then the kernel would read that when doing a NULL deref. Cheers, Ben.