From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752023Ab2LQJEs (ORCPT ); Mon, 17 Dec 2012 04:04:48 -0500 Received: from nat28.tlf.novell.com ([130.57.49.28]:37756 "EHLO nat28.tlf.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751682Ab2LQJEq convert rfc822-to-8bit (ORCPT ); Mon, 17 Dec 2012 04:04:46 -0500 Message-Id: <50CEEE3302000078000B0AC0@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.1 Date: Mon, 17 Dec 2012 09:04:35 +0000 From: "Jan Beulich" To: "Matt Fleming" , "Linus Torvalds" , "Markus Trippelsdorf" Cc: "Arnd Bergmann" , "Ingo Molnar" , "Michael Kerrisk" , "Guennadi Liakhovetski" , "Thomas Gleixner" , "H. Peter Anvin" , "Paul E. McKenney" , "Dave Jones" , "David Howells" , "Grant Likely" , "Linux Kernel Mailing List" Subject: Re: [GIT PULL] x86/uapi for 3.8 References: <201212122211.qBCMBRxl027895@terminus.zytor.com> <23916.1355356085@warthog.procyon.org.uk> <21507.1355528749@warthog.procyon.org.uk> <20121215163323.GA229@x4> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> On 15.12.12 at 19:35, Linus Torvalds wrote: > On Sat, Dec 15, 2012 at 8:33 AM, Markus Trippelsdorf > wrote: >> On 2012.12.14 at 17:47 -0800, Linus Torvalds wrote: >>> >>> Ho humm. Anybody else see anything strange? >> >> Yes. I'm seeing a BUG early during boot on my machine (RIP=NULL): >> >> BUG: unable to handle kernel NULL pointer dereference at (null) >> >> This is caused by commit 53b87cf088e2 ("x86, mm: Include the >> entire kernel memory map in trampoline_pgd") > > Hmm. That reverts cleanly, and the result boots fine for me. And the > commit looks like exactly the kind of thing that could result in > problems with exactly the right memory layout, so it could explain why > the bisect failed and some kernels randomly worked for me and others > didn't. > > So this at least looks like a very possible candidate. > > Does anybody have an explanation for the problem? How about this being caused by using the same lower level page table entries that swapper_pg_dir uses, namely including the _PAGE_GLOBAL bits? efi_call_virt_{pre,epi}log() only write CR3 (see 185034e72d591f9465e5e18f937ed642e7ea0070), but would need to also flip CR4.PGE afaict. Jan