mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>
Subject: Re: Removing entry trampoline and associated reversions
Date: Tue, 28 Aug 2018 10:02:51 +0300	[thread overview]
Message-ID: <03bee514-277e-a077-ada0-41a3aa67dd04@intel.com> (raw)
In-Reply-To: <CALCETrVNUd3YahKEjF3mwNMz-zfp9AdvK+OV8uEvSyrX9TPymA@mail.gmail.com>

On 27/08/18 19:42, Andy Lutomirski wrote:
> [gah -- accidentally hit send]
> 
> On Mon, Aug 27, 2018 at 9:42 AM, Andy Lutomirski <luto@kernel.org> wrote:
>> Hi all-
>>
>> We had an unfortunate conflict.  Adrian did all the plumbing to get
>> entry_trampoline to play nicelyh with kcore and perf.  Meanwhile, I
>> was working on getting rid of the entry trampoline.  Adrian's code is
>> merged and mine is finally in good shape, and there's an obvious
>> conflict.
>>
>> So I did a bunch of reverts, all but one of which were clean.  The
>> series is here:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/pti

We are kind of stuck with the 'perf tools' changes as they are.  That is
because CONFIG_KASAN changes the size of the cpu entry area, which means
that the kernel patches are still potentially useful for kernels from v4.15
to v4.19 incl., which in turn means we still need 'perf tools' support for them.

If we didn't want to support that, we still need the tools workaround that
hard-codes the trampoline addresses for v4.15 to v4.19.  And possibly we
would need to ensure perf.data files (and copies of kcore) with trampoline
maps recorded, are still handled correctly.

>>
>> and the messy revert is here:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/pti&id=50ef6380e448650b48db979d7d1f20a325b0a273

Should be able to get rid of KCORE_REMAP and kcore_list.vaddr also.

> 
> Is this the right approach?
> 

You could leave the tools changes to me if you want.

      reply	other threads:[~2018-08-28  7:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-27 16:42 Andy Lutomirski
2018-08-27 16:42 ` Andy Lutomirski
2018-08-28  7:02   ` Adrian Hunter [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=03bee514-277e-a077-ada0-41a3aa67dd04@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /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®