linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	x86@kernel.org, pjt@google.com, mbenes@suze.cz, jgross@suse.com,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 6/6] objtool,x86: Rewrite retpoline thunk calls
Date: Sat, 20 Feb 2021 18:41:01 +0100	[thread overview]
Message-ID: <20210220174101.GA29905@zn.tnic> (raw)
In-Reply-To: <YDE9bmaO4tOZ/HWn@hirez.programming.kicks-ass.net>

On Sat, Feb 20, 2021 at 05:48:46PM +0100, Peter Zijlstra wrote:
>  - straight line execution is always better than a round-trip to
>    somewhere else, no matter how trivial.

Sure, but not at that price. Especially not if it is waaay down in perf
profiles.

>  - supposely EIBRS (yeah, I know, there's a paper out there) should
>    result in no longer using retpolines.

Yap, supposedly both vendors have stuff like that in the works. When
that happens, we can finally use ALTERNATIVE_3 in the ratpolines. :-)

>  - I really, as in _REALLY_ don't want to do a CET enabled retpoline

WTF is that? Can we deal with one atrocity at a time pls...

>  - IOW, retpolines should be on their way out (knock on wood)

Yap, my hope too.

>  - doing this was fun :-)

I know.

>  - this stuff was mostly trivial make work stuff I could do with a head
>    full of snot and a headache.

I don't want to imagine what you'd come up with when you're all healthy
and rested. :-P

>  - if we had negative alternatives objtool doesn't need to actually
>    rewrite code in this case. It could simply emit alternative entries
>    and call it a day.

I don't mind the negative alt per se - I mind the implementation I saw.
I'm sure we can come up with something nicer, like, for example, struct
alt_instr.flags to denote that this feature is a NOT feature. IOW, I'd
like for the fact that a feature is a NOT feature or patching needs to
happen in the NOT case, to be explicitly stated with a flag. I.e.,

	if (!boot_cpu_has(a->cpuid) && !(a->flags & PATCH_WHEN_X86_FEATURE_FLAG_NOT_SET))
		continue;

Something like that.
			
>  - objtool already rewrites code

Sure, as long as one can reconstruct from looking at the asm, what
objdool has changed. I fear that'll get out of control if not done with
restraint and proper documentation.

>  - I have more cases for objtool to rewrite code (I'll see if I can
>    rebase and post that this weekend -- no promises).

Oh noes.

>  - also https://lkml.kernel.org/r/20200625200235.GQ4781@hirez.programming.kicks-ass.net

Oh well, I guess you can simply make objtool compile the kernel and be
done with it.

:)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

  reply	other threads:[~2021-02-20 17:44 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19 20:43 [RFC][PATCH 0/6] objtool: Optimize !retpoline Peter Zijlstra
2021-02-19 20:43 ` [RFC][PATCH 1/6] objtool: Correctly handle retpoline thunk calls Peter Zijlstra
2021-02-19 20:43 ` [RFC][PATCH 2/6] objtool: Fix static_call list generation Peter Zijlstra
2021-02-19 20:43 ` [RFC][PATCH 3/6] objtool: Rework rebuild_reloc logic Peter Zijlstra
2021-02-19 20:43 ` [RFC][PATCH 4/6] objtool: Add elf_create_undef_symbol() Peter Zijlstra
2021-02-19 20:43 ` [RFC][PATCH 5/6] objtool: Allow archs to rewrite retpolines Peter Zijlstra
2021-02-19 20:43 ` [RFC][PATCH 6/6] objtool,x86: Rewrite retpoline thunk calls Peter Zijlstra
2021-02-19 21:55   ` Josh Poimboeuf
2021-02-19 22:01     ` Peter Zijlstra
2021-02-20  0:39       ` Borislav Petkov
2021-02-20 16:48         ` Peter Zijlstra
2021-02-20 17:41           ` Borislav Petkov [this message]
2021-02-20 22:28             ` Peter Zijlstra
2021-02-20 22:51               ` Peter Zijlstra
2021-02-21  9:54                 ` Borislav Petkov
2021-02-20 22:32             ` Peter Zijlstra
2021-02-21  5:45               ` Jürgen Groß
2021-02-21  9:44                 ` Borislav Petkov

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=20210220174101.GA29905@zn.tnic \
    --to=bp@alien8.de \
    --cc=jgross@suse.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbenes@suze.cz \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=x86@kernel.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;
as well as URLs for NNTP newsgroup(s).