Messages in this thread | | | From | Nick Desaulniers <> | Date | Mon, 28 Sep 2020 13:32:47 -0700 | Subject | Re: general protection fault in perf_misc_flags |
| |
On Sun, Sep 27, 2020 at 10:18 PM 'Dmitry Vyukov' via Clang Built Linux <clang-built-linux@googlegroups.com> wrote: > > On Sun, Sep 27, 2020 at 4:57 PM Borislav Petkov <bp@alien8.de> 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@chromium.org> > > 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@chromium.org> > > 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?
> > +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
| |