Re: x86 - clang / objtool status

[Peter Zijlstra]

On Wed, Jul 24, 2019 at 07:55:25AM -0500, Josh Poimboeuf wrote:
> On Wed, Jul 24, 2019 at 09:47:32AM +0200, Peter Zijlstra wrote:
> > On Tue, Jul 23, 2019 at 09:43:24PM -0500, Josh Poimboeuf wrote:
> > > On Thu, Jul 18, 2019 at 10:40:09PM +0200, Thomas Gleixner wrote:
> > > 
> > > >   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: .altinstr_replacement+0x86: redundant UACCESS disable
> > > 
> > > Looking at this one, I think I agree with objtool.
> > > 
> > > PeterZ, Linus, I know y'all discussed this code a few months ago.
> > > 
> > > __copy_from_user() already does a CLAC in its error path.  So isn't the
> > > user_access_end() redundant for the __copy_from_user() error path?
> > 
> > Hmm, is this a result of your c705cecc8431 ("objtool: Track original function across branches") ?
> > 
> > I'm thinking it might've 'overlooked' the CLAC in the error path before
> > (because it didn't have a related function) and now it sees it and
> > worries about it.
> > 
> > Then again, I'm not seeing this warning on my GCC builds; so what's
> > happening?
> 
> According to the github issue[1] my patch doesn't fix the warning with
> Clang.  So questions remain:

I was thinking your patch resulted in the warning due to the exception
code gaining a ->func. But then that doesn't make sense either, because
all that lives in copy_user_64.S which is a completely different
translation unit.

> a) what is objtool actually warning about?

CLAC with AC already clear. Either we do double CLAC at the end, or we
do CLAC without having done STAC first.

The issue isn't BAD(tm), as AC clear is the safe state, but it typically
indicates confused code flow.

> b) why doesn't objtool detect the case I found?

With GCC you mean? Yes, that is really really weird.

Let me go stare at objdump output for this file (which doesn't build
with:

   make O=defconfig-build/ drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o
)