Re: [PATCH 20/24] objtool: Another static block fail

[Josh Poimboeuf]

On Tue, Jan 30, 2018 at 10:56:53AM +0100, Peter Zijlstra wrote:
> On Mon, Jan 29, 2018 at 04:52:53PM -0600, Josh Poimboeuf wrote:
> > On Tue, Jan 23, 2018 at 04:25:59PM +0100, Peter Zijlstra wrote:
> > > I've observed GCC generate:
> > > 
> > >   sym:
> > >      NOP/JMP 1f	(static_branch)
> > >      JMP 2f
> > >   1: /* crud */
> > >      JMP 3f
> > >   2: /* other crud */
> > > 
> > >   3: RETQ
> > > 
> > > 
> > > This means we need to follow unconditional jumps; be conservative and
> > > only follow if its a unique jump.
> > > 
> > > (I've not yet figured out which CONFIG option is responsible for this,
> > >  a normal defconfig build does not generate crap like this)
> > > 
> > > Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> > 
> > Any chance we can just add a compiler barrier to the assertion macro and
> > avoid all this grow_static_blocks() mess?  It seems a bit... fragile.
> 
> It is all rather unfortunate yes.. :/ I've tried to keep the grow stuff
> as conservative as possible while still covering all the weirdness I
> found. And while it was great fun, I do agree it would be much better to
> not have to do this.

The more I look at this patch, and the previous one, the less sure I am
about this idea.  (This isn't a comment about the code, just some
general uneasiness about the unpredictable GCC behavior we're trying to
constrain, and whether it's worth the pain.)

Covering all the corner cases is complicated, and it might get even more
complicated with future compiler optimizations.

What if we *only* use the assertions in places that really need them,
like the IBRS checks?  Would that allow us to simplify and drop these
last two (or three) patches? 

Or, maybe we should just forget the whole thing and just stick with the
dynamic IBRS checks with lfence.  Yes, it's less ideal for the kernel,
but adding these acrobatics to objtool also has a cost.

-- 
Josh