On Tue, May 26, 2020 at 03:26:40PM +0200, Dmitry Vyukov wrote: > On Tue, May 26, 2020 at 2:41 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.
