From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757169AbdLPXqh (ORCPT ); Sat, 16 Dec 2017 18:46:37 -0500 Received: from mail-wm0-f54.google.com ([74.125.82.54]:43339 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756737AbdLPXqf (ORCPT ); Sat, 16 Dec 2017 18:46:35 -0500 X-Google-Smtp-Source: ACJfBotrHFD3jzVd7J7rfUo5CwRFT97vQs02biJ7POK01qfWzDXpGGZwEdegxK4FsaSVBTO1FY9bRw== Date: Sun, 17 Dec 2017 00:46:31 +0100 From: Ingo Molnar To: Linus Torvalds Cc: Linux Kernel Mailing List , Thomas Gleixner , Peter Zijlstra , Borislav Petkov , "H. Peter Anvin" , Andy Lutomirski , Andrew Morton Subject: Re: [RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches Message-ID: <20171216234631.zajbgjnzs642iskg@gmail.com> References: <20171216015859.ce6axpnkoyevdtpw@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Linus Torvalds wrote: > On Fri, Dec 15, 2017 at 5:58 PM, Ingo Molnar wrote: > > > > These are the x86-64 low level entry code preparatory patches for the page table > > isolation patches - which are required for PTI, which addresses KASLR and similar > > information leaks. > > Ugh. > > Ok, I've read through this, and while I like most of it (I do like the > percpu syscall stack), I have this urge to wait until after rc4. With > the suspend/resume issues, Yeah, so as a response to those breakages I recently started testing s2ram as a regular part of -tip testing, so every tree I send to you does s2ram fine on my (suspendable) testsystems. That's still not full coverage, but should be better than what we had. > [...] we've had a horrible track record for 4.15 rc's so far, I'l like to not > pull another low-level x86 change just before an rc release and potentially make > it four for four broken rc's. Yeah, I can understand that. I knew the weekend timing is awkward, but I tried to post it as soon as I felt it was ready and as soon upstream (x86) stability looked good. > And I absolutely detest how that cherry-pick branch was done. I can > see why, but: > > - now we have those extra cherry-picks that I already have > > - and the merge commit isn't even a no-op! > > Dammit, if the point was to have a branch that worked for 4.14, I can > see that. But look at that merge (on the "other side"), and notice how > the end result is *not* identical to the parent. > > IOW, that > > 9a818d1a3235 Merge branch 'WIP.x86/pti.base' into x86/pti, to pick > up cherry-picked base tree and preparatory patches > > was supposed to be a synchronization point, but if you do > > git diff 9a818d1a3235..9a818d1a3235^ > > it isn't actually synchronized. It's *almost* synchronized, but not > quite. How did those cherry-picks that were already upstream end up > causing *changes* upstream? That's odd. > > So there are some technical oddities in there. Indeed, and I tried to make it a no-op merge, and it's _almost_ a no-op merge, except these two commits: One of the PTI namespace preparatory patches ended up in the 'base' tree: d78b637b29a2: drivers/misc/intel/pti: Rename the header file to free up the namespace plus there's this cherry-pick from a very recent upstream kernel: c3bc8b53d54c: bpf: fix build issues on um due to mising bpf_perf_event.h which was required for UML to build and be testable. We can move both commits to a later stage in the tree to make the v4.14 base tree an 'obvious' upstream-identical tree. Will respin it all tomorrow. Thanks, Ingo