mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches
Date: Sun, 17 Dec 2017 16:02:21 +0100	[thread overview]
Message-ID: <20171217150220.nmgyvkbrkgvsu3zp@gmail.com> (raw)
In-Reply-To: <20171216234631.zajbgjnzs642iskg@gmail.com>


* Ingo Molnar <mingo@kernel.org> wrote:

> > 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.

So today I've respun it all, and I think it all got cleaner. I'm going to send you 
3 pull requests:

1) a 'preparatory tree' that is a single commit that frees up the PTI namespace

2) the 'v4.14 backport base tree' which is fully synchronized an should be a no-op 
   merge on your side. I also organized it a bit better with all cherry-picks in a 
   single linear range of commits, with clear notations.

3) the 'per CPU syscall tree', which will be a clean, linear series of commits 
   with no merge distractions whatsoever.

The first two you could pull today, with very low risk levels.

Thanks,

	Ingo

      reply	other threads:[~2017-12-17 15:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-16  1:58 Ingo Molnar
2017-12-16 22:57 ` Linus Torvalds
2017-12-16 23:46   ` Ingo Molnar
2017-12-17 15:02     ` Ingo Molnar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171217150220.nmgyvkbrkgvsu3zp@gmail.com \
    --to=mingo@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®