linux-next build error (8)

syzbot

unread,

Mar 18, 2020, 12:57:15 PM3/18/20

to linux-...@vger.kernel.org, syzkall...@googlegroups.com

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+792dec...@syzkaller.appspotmail.com

kernel/rcu/tasks.h:1070:37: error: 'rcu_tasks_rude' undeclared (first use in this function); did you mean 'rcu_tasks_qs'?

---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Dmitry Vyukov

unread,

Mar 18, 2020, 4:54:21 PM3/18/20

to syzbot, Paul E. McKenney, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, r...@vger.kernel.org, LKML, syzkaller-bugs

On Wed, Mar 18, 2020 at 5:57 PM syzbot
<syzbot+792dec...@syzkaller.appspotmail.com> 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+792dec...@syzkaller.appspotmail.com
>
> kernel/rcu/tasks.h:1070:37: error: 'rcu_tasks_rude' undeclared (first use in this function); did you mean 'rcu_tasks_qs'?

+rcu maintainers

Paul E. McKenney

unread,

Mar 18, 2020, 5:41:10 PM3/18/20

to Dmitry Vyukov, syzbot, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, r...@vger.kernel.org, LKML, syzkaller-bugs

On Wed, Mar 18, 2020 at 09:54:07PM +0100, Dmitry Vyukov wrote:
> On Wed, Mar 18, 2020 at 5:57 PM syzbot
> <syzbot+792dec...@syzkaller.appspotmail.com> 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+792dec...@syzkaller.appspotmail.com
> >
> > 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.

Thanx, Paul

Dmitry Vyukov

unread,

Mar 19, 2020, 3:13:48 AM3/19/20

to Paul E. McKenney, syzbot, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, r...@vger.kernel.org, LKML, syzkaller-bugs

On Wed, Mar 18, 2020 at 10:41 PM Paul E. McKenney <pau...@kernel.org> 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+792dec...@syzkaller.appspotmail.com> 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+792dec...@syzkaller.appspotmail.com
> > >
> > > 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...
Now we need to spend time and deal with it. What has fixed it?

Paul E. McKenney

unread,

Mar 19, 2020, 11:04:16 AM3/19/20

to Dmitry Vyukov, syzbot, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, r...@vger.kernel.org, LKML, syzkaller-bugs

I do significant testing before pushing to -next, but triggering this
one requires a combination of Kconfig options that are incompatible
with rcutorture. :-/

I suppose one strategy would be to give kbuild test robot some time before
passing to -next, but they seem to sometimes get too far behind for me to
be willing to wait that long. So my current approach is to push my "dev"
branch, run moderate rcutorture testing (three hours per scenario other
than TREE10, which gets only one hour), and if that passes, push to -next.

I suppose that I could push to -next only commits that are at least three
days old or some such. But I get in trouble pushing to -next too slowly
as often as I get in trouble pushing too quickly, so I suspect that my
current approach is in roughly the right place.

> Now we need to spend time and deal with it. What has fixed it?

It is fixed by commit c6ef38e4d595 ("rcu-tasks: Add RCU tasks to
rcutorture writer stall output") and some of its predecessors.

Perhaps more useful to you, this commit is included in next-20200319
from the -next tree. ;-)

Thanx, Paul

Dan Carpenter

unread,

Mar 20, 2020, 9:11:18 AM3/20/20

to Dmitry Vyukov, Paul E. McKenney, syzbot, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, r...@vger.kernel.org, LKML, syzkaller-bugs

We could make a mailing list for recording it, and then just grep the
mailbox for the file and function.

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

regards,
dan carpenter

Dmitry Vyukov

unread,

Mar 20, 2020, 11:39:07 AM3/20/20

to Paul E. McKenney, syzbot, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, r...@vger.kernel.org, LKML, syzkaller-bugs

Let's tell syzbot about the fix:

#syz fix: rcu-tasks: Add RCU tasks to rcutorture writer stall output

I think what you are doing is the best possible option in the current situation.
I don't think requiring all human maintainers to do more manual
repetitive work, which is not well defined and even without a way to
really require something from them is scalable nor reliable nor the
right approach.

We would consume something like LKGR [1] if it existed for the kernel.
But it would require tighter integration of testing systems with
kernel dev processes, or of course throwing more manual labor at it to
track all uncoordinated testing systems and publishing LKGR tags.

[1] https://chromium.googlesource.com/chromiumos/docs/+/master/glossary.md

Dmitry Vyukov

unread,

Mar 20, 2020, 11:42:40 AM3/20/20

to Dan Carpenter, Paul E. McKenney, syzbot, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, r...@vger.kernel.org, LKML, syzkaller-bugs

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).

Paul E. McKenney

unread,

Mar 20, 2020, 12:26:52 PM3/20/20

to Dmitry Vyukov, syzbot, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, r...@vger.kernel.org, LKML, syzkaller-bugs

Thank you, and I do greatly appreciate the automation!

> We would consume something like LKGR [1] if it existed for the kernel.
> But it would require tighter integration of testing systems with
> kernel dev processes, or of course throwing more manual labor at it to
> track all uncoordinated testing systems and publishing LKGR tags.
>
> [1] https://chromium.googlesource.com/chromiumos/docs/+/master/glossary.md

At my end, it is pretty quick and easy to detect duplicate notifications
of the same bug, so the current situation isn't causing me undue distress.

Thanx, Paul

Randy Dunlap

unread,

Mar 20, 2020, 12:34:17 PM3/20/20

to pau...@kernel.org, Dmitry Vyukov, syzbot, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, r...@vger.kernel.org, LKML, syzkaller-bugs

Yeah, I saw the same build error and did-not-report it since it was
already reported. :)

--
~Randy

Paul E. McKenney

unread,

Mar 20, 2020, 1:04:42 PM3/20/20

to Randy Dunlap, Dmitry Vyukov, syzbot, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, r...@vger.kernel.org, LKML, syzkaller-bugs

Much appreciated! ;-)

Thanx, Paul

Tetsuo Handa

unread,

May 22, 2020, 12:29:28 AM5/22/20

to Dmitry Vyukov, syzbot, syzkall...@googlegroups.com

Hello.

This report is already reporting next problem. Since the location seems to be
different, this might be caused by OOM due to too much parallel compilation.
Maybe syzbot can detect "gcc: fatal error: Killed signal terminated program cc1"
sequence and retry with reduced "make -j$NUM" settings.

gcc: fatal error: Killed signal terminated program cc1
compilation terminated.
scripts/Makefile.build:272: recipe for target 'fs/xfs/libxfs/xfs_btree.o' failed
make[2]: *** [fs/xfs/libxfs/xfs_btree.o] Error 1
make[2]: *** Waiting for unfinished jobs....

Dmitry Vyukov

unread,

May 26, 2020, 8:09:41 AM5/26/20

to Tetsuo Handa, Linux-Next Mailing List, Stephen Rothwell, Darrick J. Wong, linux-xfs, syzbot, syzkaller-bugs

+linux-next and XFS maintainers

Interesting. This seems to repeat reliably and this machine is not
known for any misbehavior and it always happens on all XFS files.
Did XFS get something that crashes gcc's?

CC drivers/hid/hid-uclogic-rdesc.o
CC drivers/hid/hid-uclogic-params.o
CC drivers/hid/hid-led.o
CC drivers/hid/hid-zpff.o
CC drivers/hid/hid-zydacron.o
CC drivers/hid/wacom_wac.o
CC drivers/hid/wacom_sys.o
CC drivers/hid/hid-waltop.o
CC drivers/hid/hid-wiimote-core.o
CC drivers/hid/hid-wiimote-debug.o
CC drivers/hid/hid-wiimote-modules.o
CC drivers/hid/usbhid/hid-core.o
CC drivers/hid/usbhid/hid-pidff.o
CC drivers/hid/usbhid/hiddev.o
AR drivers/gpu/drm/i915/built-in.a
AR drivers/gpu/drm/built-in.a
AR drivers/gpu/built-in.a