Messages in this thread | | | Date | Wed, 24 Jul 2019 15:35:16 +0200 | From | Peter Zijlstra <> | Subject | Re: x86 - clang / objtool status |
| |
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 )
| |