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=-6.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_PASS autolearn=ham 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 DD718C43387 for ; Tue, 18 Dec 2018 14:13:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B4513218A2 for ; Tue, 18 Dec 2018 14:13:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727015AbeLRONI (ORCPT ); Tue, 18 Dec 2018 09:13:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45350 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726616AbeLRONI (ORCPT ); Tue, 18 Dec 2018 09:13:08 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C4DD4C049E12; Tue, 18 Dec 2018 14:13:07 +0000 (UTC) Received: from localhost (ovpn-200-20.brq.redhat.com [10.40.200.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D38EC10595B1; Tue, 18 Dec 2018 14:13:03 +0000 (UTC) Date: Tue, 18 Dec 2018 15:12:58 +0100 From: Stefano Brivio To: Dmitry Vyukov Cc: Eric Dumazet , Arjan van de Ven , "Paul E. McKenney" , Andrew Morton , Josh Triplett , LKML , Ingo Molnar , syzkaller-bugs , netdev , Cong Wang , Xin Long Subject: Re: WARNING in __rcu_read_unlock Message-ID: <20181218151258.38796e76@redhat.com> In-Reply-To: References: <0000000000005e47a2057d0edc49@google.com> <20181216190412.GE4170@linux.ibm.com> <20181217112916.GG4170@linux.ibm.com> <1583d5fc-34bf-3a81-363d-01a1085a7363@linux.intel.com> <20641819-e4fb-f3bd-34c8-c68106cccd0e@gmail.com> <20181217162421.6d636ee5@redhat.com> <20181218001828.49cea463@redhat.com> <20181218134024.45d2d5e3@redhat.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 18 Dec 2018 14:13:08 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Dropping syzbot from Cc:] On Tue, 18 Dec 2018 14:26:00 +0100 Dmitry Vyukov wrote: > On Tue, Dec 18, 2018 at 1:40 PM Stefano Brivio > wrote: > > > Maybe it would be nice to have a semi-automated way to isolate and > > describe/name specific conditions found by syzbot via fuzzing and > > turn those into tests that are then repeated periodically. I'm not > > sure how that would look like, but I think it's still more > > maintainable than a pile of C reproducers with forged packets in > > selftests/net. > > It would be nice to do something like this. Filed > https://github.com/google/syzkaller/issues/884 > However, there are few open questions that I am not sure how to > resolve yet... I don't have a github account, so let me comment on your questions here: > 1. How to effectively fetch so many repros from datastore without > hitting timeouts? We probably need to limit this to 1 repro per bug, > but still that's many repros. I guess this would be less of a problem if reproducers are selected based on input from developers, instead of just taking all the reproducers. E.g. one could answer a report with something like: #syz regression-test: in this case I would have answered: #syz regression-test: icmp-udp-in-gue-recursion ICMP exceptions on UDP direct encapsulation in GUE and something could be automatically appended to the test name, perhaps e-mail and date. It would also be nice to be able to undo this and delete a regression test. > 2. Do we need some sorting based on namespace? E.g. stable releases > may not include fixes for bugs fixed in upstream, then we will just > crash lots of kernels in vain. Same here, I guess developer input might help, but I'm not sure how to formalise this. > 3. syzkaller repros depend on exact syzkaller revision, new syzkaller > won't be able to use old repros. Using C repros is much harder and > they are not present for all bugs. Not sure what to do here. Would it make a difference if you could use the "syz" reproducers and translate them to C reproducer only once needed? -- Stefano