Subject: Re: linux-next build error (8)

From: Qian Cai <[email-masked]>
Date: Tue, 26 May 2020 09:49:53 -0400

On Tue, May 26, 2020 at 03:26:40PM +0200, Dmitry Vyukov wrote:
> On Tue, May 26, 2020 at 2:41 PM Qian Cai <[email-masked]> wrote:
> >
> >
> >
> > > On May 26, 2020, at 8:28 AM, Dmitry Vyukov <[email-masked]> 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.