Re: linux-next build error (8)

[Dmitry Vyukov]

On Fri, Mar 20, 2020 at 2:11 PM Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote:
>
> On Thu, Mar 19, 2020 at 08:13:35AM +0100, 'Dmitry Vyukov' via syzkaller-bugs wrote:
> > On Wed, Mar 18, 2020 at 10:41 PM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote:
> > >
> > > On Wed, Mar 18, 2020 at 09:54:07PM +0100, Dmitry Vyukov wrote:
> > > > On Wed, Mar 18, 2020 at 5:57 PM syzbot
> > > > <syzbot+792dec47d693ccdc05a0@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > syzbot found the following crash on:
> > > > >
> > > > > HEAD commit:    47780d78 Add linux-next specific files for 20200318
> > > > > git tree:       linux-next
> > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=14228745e00000
> > > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=b68b7b89ad96c62a
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=792dec47d693ccdc05a0
> > > > > compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> > > > >
> > > > > Unfortunately, I don't have any reproducer for this crash yet.
> > > > >
> > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > Reported-by: syzbot+792dec47d693ccdc05a0@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > > >
> > > > > kernel/rcu/tasks.h:1070:37: error: 'rcu_tasks_rude' undeclared (first use in this function); did you mean 'rcu_tasks_qs'?
> > > >
> > > > +rcu maintainers
> > >
> > > The kbuild test robot beat you to it, and apologies for the hassle.
> > > Fixed in -rcu on current "dev" branch.
> >
> > If the kernel dev process would only have a way to avoid dups from all
> > test systems...
>
> We could make a mailing list for recording it, and then just grep the
> mailbox for the file and function.

As far as I understand Paul was already aware of the breakage and both
reports. Also how do we make all kernel testing out there to respect
this new list?....

> Or we could just assume that kbuild is going to find almost all the
> build errors.

Paul mentioned that they don't sometimes ("but they seem to sometimes
get too far behind for me to
be willing to wait that long"). Lots of people mentioned this on the
last LPC as well. It's not completely transparent and not part of the
kernel project to rely on it (how do we add new configs? how do we
urgently repair it? etc).