Re: general protection fault in perf_misc_flags

[Dmitry Vyukov]

On Mon, Sep 28, 2020 at 10:33 PM Nick Desaulniers
<ndesaulniers@xxxxxxxxxx> wrote:
>
> On Sun, Sep 27, 2020 at 10:18 PM 'Dmitry Vyukov' via Clang Built Linux
> <clang-built-linux@xxxxxxxxxxxxxxxx> wrote:
> >
> > On Sun, Sep 27, 2020 at 4:57 PM Borislav Petkov <bp@xxxxxxxxx> wrote:
> > >
> > > On Sat, Sep 19, 2020 at 01:32:14AM -0700, syzbot wrote:
> > > > Hello,
> > > >
> > > > syzbot found the following issue on:
> > > >
> > > > HEAD commit:    92ab97ad Merge tag 'sh-for-5.9-part2' of git://git.libc.or..
> > > > git tree:       upstream
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1069669b900000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=cd992d74d6c7e62
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=ce179bc99e64377c24bc
> > > > compiler:       clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
> > >
> > > All below is AFAICT:
> > >
> > > This compiler you're using is not some official release but some random
> > > commit before the v10 release:
> > >
> > > $ git show c2443155a0fb245c8f17f2c1c72b6ea391e86e81
> > > Author: Hans Wennborg <hans@xxxxxxxxxxxx>
> > > Date:   Sat Nov 30 14:20:11 2019 +0100
> > >
> > >     Revert 651f07908a1 "[AArch64] Don't combine callee-save and local stack adjustment when optimizing for size"
> > > ...
> > >
> > > $ git describe c2443155a0fb245c8f17f2c1c72b6ea391e86e81
> > > llvmorg-10-init-10900-gc2443155a0fb
> > >
> > > The v10 release is:
> > >
> > > $ git show llvmorg-10.0.0
> > > tag llvmorg-10.0.0
> > > Tagger: Hans Wennborg <hans@xxxxxxxxxxxx>
> > > Date:   Tue Mar 24 12:58:58 2020 +0100
> > >
> > > Tag 10.0.0
> > >
> > > and v10 has reached v10.0.1 in the meantime:
> > >
> > > $ git log --oneline c2443155a0fb245c8f17f2c1c72b6ea391e86e81~1..llvmorg-10.0.1 | wc -l
> > > 7051
> > >
> > > so can you please update your compiler and see if you can still
> > > reproduce with 10.0.1 so that we don't waste time chasing a bug which
> > > has been likely already fixed in one of those >7K commits.
>
> Oh, shoot, sorry I didn't catch that. Good find.  My next question was
> going to be if this is reproducible with a newer compiler release or
> not (later emails make this sound like it's no longer considered clang
> specific).
>
> Generally we want coverage of unreleased compiler versions to ensure
> we don't ship a broken release.  Once the release exists, it's of
> questionable value to continue to test a pre-release version of that
> branch.
>
> This isn't the first time where we've had syzcaller reports that were
> testing old releases of clang.  Maybe we can establish a process for
> upgrading the toolchain under test based on some time based cadence,
> or coinciding with the upstream LLVM release events?

The current hypothesis is that this bug is not related to clang (there
are similar crashes with gcc as well).
We use unreleased versions of clang as we frequently need recent
fixes/features. And then later nobody usually has time to update, if
things work.
Based on offline discussion with Marco, we probably need to update
KMSAN and KASAN to 11 release when it's released.


> > +Alex, Marco,
> >
> > There is suspicion that these may be caused by use of unreleased clang.
> > Do we use the same clang as we use for the KMSAN instance? But this is
> > not KMSAN machine, so I am not sure who/when/why updated it last to
> > this revision.
> > I even see we have some clang 11 version:
> > https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce
> >
> > Is it possible to switch to some released version for both KMSAN and KASAN now?
> --
> Thanks,
> ~Nick Desaulniers