Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752479AbeAESPY (ORCPT + 1 other); Fri, 5 Jan 2018 13:15:24 -0500 Received: from mail.kernel.org ([198.145.29.99]:42380 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752038AbeAESPW (ORCPT ); Fri, 5 Jan 2018 13:15:22 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EFCA221928 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org X-Google-Smtp-Source: ACJfBotUTkZ3iBlbA/jN+Uq2z+Z+hY6uXg1iBoLZXGUQF7fztWcR+fMEs3yyEmBK3Qelxt+kYz93iDiWzOl4ZT5m20U= MIME-Version: 1.0 In-Reply-To: <20180105175229.GA29834@kroah.com> References: <20180105145958.GB12951@kroah.com> <630fd5c7-61bb-6af7-897e-b3ac254730bb@oracle.com> <192D254D-57C6-49F0-809C-2391FCB4F341@amacapital.net> <0C00DC80-5F7E-4417-872D-66473A6387A0@amacapital.net> <20180105175229.GA29834@kroah.com> From: Andy Lutomirski Date: Fri, 5 Jan 2018 10:15:00 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4.4 00/37] 4.4.110-stable review To: Greg Kroah-Hartman Cc: Pavel Tatashin , Hugh Dickins , Linus Torvalds , Thomas Voegtle , Linux Kernel Mailing List , Andrew Morton , Guenter Roeck , Shuah Khan , patches@kernelci.org, Ben Hutchings , lkft-triage@lists.linaro.org, stable Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Fri, Jan 5, 2018 at 9:52 AM, Greg Kroah-Hartman wrote: > On Fri, Jan 05, 2018 at 12:48:54PM -0500, Pavel Tatashin wrote: >> Boots successfully with "noefi" kernel parameter :) > > Thanks, that will help me narrow it down. I'll dig through more patches > when I get home tonight... I wish you luck. The 4.4 series is "KAISER", not "KPTI", and the relevant code is spread all over the place and is generally garbage. See, for example, the turd called kaiser_set_shadow_pgd(). I would not be terribly surprised if that particular turd is biting here. An alternative theory is that something is screwy in the EFI code. I don't see anything directly wrong, but it's certainly a bit sketchy. The newer kernels carefully avoid using PCID 0 for real work to avoid corruption due to EFI and similar things. The "KAISER" code has no such mitigation. Fortunately, it seems to use PCID=0 for kernel and PCID=nonzero for user, so the obvious problem isn't present, but something could still be wrong. Pavel, can you send your /proc/cpuinfo on a noefi boot? (Just the first CPU worth is fine.) FWIW, I said before that I have very little desire to help debug "KAISER". I stand by that.