linux-kernel - Re: linux-next build error (8)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+YHQQWeeW44NYAxX+fFU6RyvFbbmcig1q8NSE7yV0zgjA@mail.gmail.com>
Date:   Fri, 20 Mar 2020 16:38:54 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     syzbot <syzbot+792dec47d693ccdc05a0@...kaller.appspotmail.com>,
        Josh Triplett <josh@...htriplett.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Joel Fernandes <joel@...lfernandes.org>, rcu@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: linux-next build error (8)

On Thu, Mar 19, 2020 at 4:04 PM Paul E. McKenney <paulmck@...nel.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@...nel.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@...kaller.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@...kaller.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