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@xxxxxxxxxx> 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@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... > > > > 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
