From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A368C4332E for ; Fri, 20 Mar 2020 16:26:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5258020739 for ; Fri, 20 Mar 2020 16:26:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584721615; bh=GRkJPRXSUPxB/4FaDSLTXZXzBr8dpjV+3HyNoC/Gdos=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:List-ID: From; b=zNOD8dtn2vJKBs5re8iuijKoBmoG/PTdc1jhdqdyyXiOwfWFTDaGBe/rivBvJcrGJ EcbidrfCs6DA6/Eu2hYx5gKkOH7GPl2ZyqjpT3dSAmghuEMn1p9cDakwqzwThAHHpb /emJJokIAzXjSpluOf/IumD1JnT1lswuJMd8EAl4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727304AbgCTQ0x (ORCPT ); Fri, 20 Mar 2020 12:26:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:52636 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727122AbgCTQ0w (ORCPT ); Fri, 20 Mar 2020 12:26:52 -0400 Received: from paulmck-ThinkPad-P72.home (50-39-105-78.bvtn.or.frontiernet.net [50.39.105.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2DD6D20724; Fri, 20 Mar 2020 16:26:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584721611; bh=GRkJPRXSUPxB/4FaDSLTXZXzBr8dpjV+3HyNoC/Gdos=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=E4YH+CNNo4ZnxnlmBJyLRcAUJDx8wp7GFj5JquWhmYs0ptqbKyXi6+JURFaKi02zi ksBlpCIcrtMfQfq8cmv7BXcEQW6gySqmpoCU/FpVh5HD2YbRnBjvSfoubAmM1rCXSC BIOFSDlRNd4e42leZi4PoTcQX4N7Hb4Edov12V7Q= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id 00E7035226B4; Fri, 20 Mar 2020 09:26:50 -0700 (PDT) Date: Fri, 20 Mar 2020 09:26:50 -0700 From: "Paul E. McKenney" To: Dmitry Vyukov Cc: syzbot , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Joel Fernandes , rcu@vger.kernel.org, LKML , syzkaller-bugs Subject: Re: linux-next build error (8) Message-ID: <20200320162650.GP3199@paulmck-ThinkPad-P72> Reply-To: paulmck@kernel.org References: <000000000000ae2ab305a123f146@google.com> <20200318214109.GV3199@paulmck-ThinkPad-P72> <20200319150414.GD3199@paulmck-ThinkPad-P72> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 wrote: > > > > > > > > On Wed, Mar 18, 2020 at 09:54:07PM +0100, Dmitry Vyukov wrote: > > > > > On Wed, Mar 18, 2020 at 5:57 PM syzbot > > > > > 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