Re: [PATCH 2/2] objtool: Optimize/fix retpoline alternative generation

[Josh Poimboeuf <jpoimboe@redhat.com>]

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