All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, mbenes@suse.cz
Subject: Re: [PATCH 2/2] objtool: Optimize/fix retpoline alternative generation
Date: Fri, 8 Oct 2021 09:39:06 -0700	[thread overview]
Message-ID: <20211008163906.e5kbzwi2slldk6gh@treble> (raw)
In-Reply-To: <YWAe7RSvYqdpbABf@hirez.programming.kicks-ass.net>

On Fri, Oct 08, 2021 at 12:35:25PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 08, 2021 at 12:23:25AM -0700, Josh Poimboeuf wrote:
> > On Thu, Oct 07, 2021 at 11:22:13PM +0200, Peter Zijlstra wrote:
> > > When re-running objtool it will generate alterantives for all
> > 
> > "alternatives"
> > 
> > > retpoline hunks, even if they are already present.
> > > 
> > > Discard the retpoline alternatives later so we can mark the
> > 
> > Discard? or mark as ignored?
> 
> I used 'discard' since we don't actually generate insn->alts entries.

I still don't like 'discard', it sounds like you're removing the
existing ALTERNATIVE from the file.

> > BTW, this "re-running objtool" thing is probably a bigger problem that
> > can be handled more broadly.  When writing an object, we could write a
> > dummy discard section ".discard.objtool_wuz_here" which tells it not to
> > touch it a second time as weird things could happen.
> 
> Section can't work, since we run the first pass on individual
> translations units, so if we get the wuz_here tag from one TU we can't
> tell if we perhaps forgot to run on another.
> 
> Better detecting if there's actual work to do seems safer to me.

I *really* don't like writing an ITU and then later writing it again as
part of bigger a linked object.  It's just going to introduce a lot of
bugs and a lot of individual "did I do this yet?" checks that we'll
forget to do half the time.

If we "perhaps forgot to run on another", and if that's a problem, then
shouldn't it be a warning when we detect it?

What specific scenarios were you thinking about?

> What I actually did yesterday was hack up --noinstr to WARN if there was
> an elf modification done, I could turn that into a --ro flag or
> something, which we can set on vmlinux if it's supposed to be a pure
> validation pass.

That might be useful, --dry-run or so.  Also useful for re-running
objtool with --backtrace to get more details about a warning.

> Subject: objtool: Optimize retpoline alternative generation
> From: Peter Zijlstra <peterz@infradead.org>
> Date: Thu Oct 7 23:15:34 CEST 2021
> 
> When re-running objtool it will generate alternatives for all
> retpoline hunks, even if they are already present.
> 
> Instead of early discarding the retpoline alterantives, hang onto them

s/alterantives/alternatives/

> @@ -1477,6 +1477,17 @@ static int add_special_section_alts(stru
>  				ret = -1;
>  				goto out;
>  			}
> +
> +			/*
> +			 * Don't generate alternative instruction streams
> +			 * (insn->alts) but instead mark the retpoline call as
> +			 * already having an alternative, so that we can avoid
> +			 * generating another instance.
> +			 */

But this also means that branch validation will get skipped on this alt,
right?  Can you mention that here, and why it's not a problem?

> +			if (new_insn->func && arch_is_retpoline(new_insn->func)) {
> +				orig_insn->ignore_alts = true;
> +				continue;
> +			}

-- 
Josh


  reply	other threads:[~2021-10-08 16:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-07 21:22 [PATCH 0/2] objtool: Avoid pointless modifications Peter Zijlstra
2021-10-07 21:22 ` [PATCH 1/2] objtool: Optimize re-writing jump_label Peter Zijlstra
2021-10-08  6:55   ` Josh Poimboeuf
2021-10-08 10:03     ` Peter Zijlstra
2021-10-08 16:28       ` Josh Poimboeuf
2021-10-07 21:22 ` [PATCH 2/2] objtool: Optimize/fix retpoline alternative generation Peter Zijlstra
2021-10-08  7:23   ` Josh Poimboeuf
2021-10-08 10:35     ` Peter Zijlstra
2021-10-08 16:39       ` Josh Poimboeuf [this message]
2021-10-09 10:42         ` Peter Zijlstra

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=20211008163906.e5kbzwi2slldk6gh@treble \
    --to=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=peterz@infradead.org \
    --subject='Re: [PATCH 2/2] objtool: Optimize/fix retpoline alternative generation' \
    /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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.