On Tue, May 26, 2020 at 3:50 PM Qian Cai <cai@xxxxxx> wrote: > > > > On May 26, 2020, at 8:28 AM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > > > > > > > > Crashes (4): > > > > Manager Time Kernel Commit Syzkaller Config Log Report Syz repro C repro > > > > ci-upstream-linux-next-kasan-gce-root 2020/05/22 01:23 linux-next > > > > e8f32747 5afa2ddd .config log report > > > > ci-upstream-linux-next-kasan-gce-root 2020/05/21 15:01 linux-next > > > > e8f32747 1f30020f .config log report > > > > ci-upstream-linux-next-kasan-gce-root 2020/05/19 18:24 linux-next > > > > fb57b1fa 6d882fd2 .config log report > > > > ci-upstream-linux-next-kasan-gce-root 2020/03/18 16:19 linux-next > > > > 47780d78 0a96a13c .config log report > > > > > > You’ll probably need to use an known good kernel version. For > > > example, a stock kernel or any of a mainline -rc / GA kernel to > > > compile next-20200526 and then test from there. > > > > People also argued for the opposite -- finding bugs only on rc's is > > too late. I think Linus also did not want bugs from entering the > > mainline tree. > > > > Ideally, all kernel patches tested on CI for simpler bugs before > > entering any tree. And then fuzzing finds only harder to hit bugs. > > syzbot is a really poor CI and it wasn't built to be a one. > > I had only suggested it as a way to workaround/confirm this bug which > will cause abormal memory usage for compilation workloads. Once you get > a working next-0526 kernel, you should be able to use that to compile > future -next trees. > > I would also agree that our maintainers should make the quality bar > higher for linux-next commits, so I could get some vacations. :) true
