Re: linux-next build error (8)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux