Re: [PATCH 00/22] x86, objtool: several fixes/improvements

[Nick Desaulniers]

On Tue, Jul 16, 2019 at 4:17 PM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
>
> On Mon, Jul 15, 2019 at 02:45:39PM -0700, Nick Desaulniers wrote:
> > For a defconfig, that's the only issue I see.
> > (Note that I just landed https://reviews.llvm.org/rL366130 for fixing
> > up bugs from loop unrolling loops containing asm goto with Clang, so
> > anyone else testing w/ clang will see fewer objtool warnings with that
> > patch applied.  A follow up is being worked on in
> > https://reviews.llvm.org/D64101).
> >
> > For allmodconfig:
> > arch/x86/ia32/ia32_signal.o: warning: objtool:
> > ia32_setup_rt_frame()+0x247: call to memset() with UACCESS enabled
> > mm/kasan/common.o: warning: objtool: kasan_report()+0x52: call to
> > __stack_chk_fail() with UACCESS enabled
> > arch/x86/kernel/signal.o: warning: objtool:
> > x32_setup_rt_frame()+0x255: call to memset() with UACCESS enabled
> > arch/x86/kernel/signal.o: warning: objtool: __setup_rt_frame()+0x254:
> > call to memset() with UACCESS enabled
> > drivers/ata/sata_dwc_460ex.o: warning: objtool:
> > sata_dwc_bmdma_start_by_tag()+0x3a0: can't find switch jump table
> > lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0x88:
> > call to memset() with UACCESS enabled
> > lib/ubsan.o: warning: objtool: ubsan_type_mismatch_common()+0x610:
> > call to __stack_chk_fail() with UACCESS enabled
> > lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0x88:
> > call to memset() with UACCESS enabled
> > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
> > .altinstr_replacement+0x56: redundant UACCESS disable
> >
> > Without your series, I see them anyways, so I don't consider them
> > regressions added by this series.  Let's follow up on these maybe in a
> > new thread?  (Shall I send you these object files?)
>
> Yes, maybe open a new thread and be sure to copy PeterZ.  He loves those
> warnings ;-)  Object files are definitely needed.
>
> > So for the series:
> > Tested-by: Nick Desaulniers <ndesaulniers@xxxxxxxxxx>
>
> Thanks!
>
> >
> > > >
> > > >    I haven't dug into it yet.
> > > >
> > > > 2) There's also an issue in clang where a large switch table had a bunch
> > > >    of unused (bad) entries.  It's not a code correctness issue, but
> > > >    hopefully it can get fixed in clang anyway.  See patch 20/22 for more
> > > >    details.
> >
> > Thanks for the report, let's follow up on steps for me to reproduce.
>
> Just to clarify, there are two clang issues.  Both of them were reported
> originally by Arnd, IIRC.
>
> 1) The one described above and in patch 20, where the switch table is
>    mostly unused entries.  Not a real bug, but it's a bit sloppy and
>    wasteful, and objtool doesn't know how to interpret it.

Thanks for the concise reports.  Will follow up on these in:
https://github.com/ClangBuiltLinux/linux/issues/611

>
> 2) The bug with the noreturn call site having a different stack size
>    depending on which code path was taken.

and:
https://github.com/ClangBuiltLinux/linux/issues/612
-- 
Thanks,
~Nick Desaulniers