Re: linux-next build error (8)

Re: linux-next build error (8)

[Dmitry Vyukov]

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

> ---
> 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 syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: linux-next build error (8)

[Paul E. McKenney]

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.

							Thanx, Paul

> > ---
> > 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 syzkaller@googlegroups.com.
> >
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: linux-next build error (8)

[Dmitry Vyukov]

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...
Now we need to spend time and deal with it. What has fixed it?

Re: linux-next build error (8)

[Paul E. McKenney]

On Thu, Mar 19, 2020 at 08:13:35AM +0100, Dmitry Vyukov 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...

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

Re: linux-next build error (8)

[Dmitry Vyukov]

On Thu, Mar 19, 2020 at 4:04 PM Paul E. McKenney <paulmck@kernel.org> wrote:
>
> On Thu, Mar 19, 2020 at 08:13:35AM +0100, Dmitry Vyukov 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...
>
> 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.  ;-)

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

Re: linux-next build error (8)

[Paul E. McKenney]

On Fri, Mar 20, 2020 at 04:38:54PM +0100, Dmitry Vyukov wrote:
> On Thu, Mar 19, 2020 at 4:04 PM Paul E. McKenney <paulmck@kernel.org> wrote:
> >
> > On Thu, Mar 19, 2020 at 08:13:35AM +0100, Dmitry Vyukov 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...
> >
> > 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.  ;-)
> 
> 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.

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

Re: linux-next build error (8)

[Randy Dunlap]

On 3/20/20 9:26 AM, Paul E. McKenney wrote:
> On Fri, Mar 20, 2020 at 04:38:54PM +0100, Dmitry Vyukov wrote:
>> On Thu, Mar 19, 2020 at 4:04 PM Paul E. McKenney <paulmck@kernel.org> wrote:
>>>
>>> On Thu, Mar 19, 2020 at 08:13:35AM +0100, Dmitry Vyukov 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...
>>>
>>> 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.  ;-)
>>
>> 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.
> 
> 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.

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

-- 
~Randy

Re: linux-next build error (8)

[Paul E. McKenney]

On Fri, Mar 20, 2020 at 09:34:13AM -0700, Randy Dunlap wrote:
> On 3/20/20 9:26 AM, Paul E. McKenney wrote:
> > On Fri, Mar 20, 2020 at 04:38:54PM +0100, Dmitry Vyukov wrote:
> >> On Thu, Mar 19, 2020 at 4:04 PM Paul E. McKenney <paulmck@kernel.org> wrote:
> >>>
> >>> On Thu, Mar 19, 2020 at 08:13:35AM +0100, Dmitry Vyukov 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...
> >>>
> >>> 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.  ;-)
> >>
> >> 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.
> > 
> > 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.
> 
> Yeah, I saw the same build error and did-not-report it since it was
> already reported.  :)

Much appreciated!  ;-)

							Thanx, Paul

Re: linux-next build error (8)

[Dan Carpenter]

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.

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

regards,
dan carpenter

Re: linux-next build error (8)

[Dmitry Vyukov]

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