Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751788AbdLBNeX (ORCPT ); Sat, 2 Dec 2017 08:34:23 -0500 Received: from mail-pg0-f53.google.com ([74.125.83.53]:34453 "EHLO mail-pg0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751699AbdLBNeW (ORCPT ); Sat, 2 Dec 2017 08:34:22 -0500 X-Google-Smtp-Source: AGs4zMaS6R6zsNiWPzEKdTTT+Z4XFhAKWD2S1EEocvcvQC8ffz/7SIySOPnEUbhe/6UmtIm/vzeJQQ== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [PATCH 1/2] Undo the split of setup_cpu_entry_area From: Andy Lutomirski X-Mailer: iPhone Mail (15B202) In-Reply-To: Date: Sat, 2 Dec 2017 05:34:19 -0800 Cc: Andy Lutomirski , X86 ML , Borislav Petkov , "linux-kernel@vger.kernel.org" , Brian Gerst , Dave Hansen , Linus Torvalds , Josh Poimboeuf Content-Transfer-Encoding: 7bit Message-Id: <24F4CAC3-6596-4DCD-AC91-4BAF5F2B18B7@amacapital.net> References: To: Thomas Gleixner Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1265 Lines: 31 > On Dec 2, 2017, at 2:47 AM, Thomas Gleixner wrote: > >> On Sat, 2 Dec 2017, Thomas Gleixner wrote: >> >>> On Fri, 1 Dec 2017, Andy Lutomirski wrote: >>> >>> This is obviously a hack. Either the patch should be adjusted back to >>> the version I sent or trap_init should forcibly initialize all PMDs >>> by something like __set_fixmap(..., __mkpte(0)); or however it's spelled. >> >> I split it because the whole thing crashed when I kept the loop you had >> because it tried to allocate stuff. Had no time to figure out why, so I >> went the lazy way of making it "work". > > [ 0.000000] dump_stack+0x85/0xc5 > [ 0.000000] warn_alloc+0x114/0x1c0 > [ 0.000000] __alloc_pages_slowpath+0x1089/0x10d0 > [ 0.000000] __alloc_pages_nodemask+0x2e8/0x370 > [ 0.000000] __get_free_pages+0x10/0x40 > [ 0.000000] kpti_shadow_pagetable_walk+0x2b2/0x3e0 > [ 0.000000] kpti_add_user_map+0xfe/0x330 > [ 0.000000] kpti_add_mapping_cpu_entry+0x5a/0x100 > [ 0.000000] trap_init+0x2c/0x7b > [ 0.000000] start_kernel+0x24c/0x497 > [ 0.000000] secondary_startup_64+0xa5/0xb0 > > Cute, isn't it? And then further down the line it triplefaults of course. Hmm. My second patch should make this go away, though.