Messages in this thread | | | From | Dmitry Vyukov <> | Date | Fri, 20 Mar 2020 16:42:28 +0100 | Subject | Re: linux-next build error (8) |
| |
On Fri, Mar 20, 2020 at 2:11 PM Dan Carpenter <dan.carpenter@oracle.com> 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@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+792dec47d693ccdc05a0@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+792dec47d693ccdc05a0@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... > > 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).
| |