Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <0000000000005e47a2057d0edc49@google.com> <20181216190412.GE4170@linux.ibm.com>
 <CACT4Y+b+mSs2FV3BY+MsHDTPPgvPaCdMmJONd9c4zEU67CdmOA@mail.gmail.com>
 <20181217112916.GG4170@linux.ibm.com> <1583d5fc-34bf-3a81-363d-01a1085a7363@linux.intel.com>
 <CACT4Y+aKn4XsGVgt3ELGnnJcg6H-m+dSdV018dLvJhrpshycWA@mail.gmail.com>
 <20641819-e4fb-f3bd-34c8-c68106cccd0e@gmail.com> <20181217162421.6d636ee5@redhat.com>
 <CACT4Y+YXFrnQh9h1KQf8=NcHugmxTj+d7AQdGCvRX_xsHwr1qA@mail.gmail.com>
 <20181218001828.49cea463@redhat.com> <CACT4Y+ZFpO26Tgqpi+Jies9XOiiCgAdp2DV0z_54hCNTqkJsiw@mail.gmail.com>
 <20181218134024.45d2d5e3@redhat.com> <CACT4Y+az3--Y2f0OKSbF0kxwckdkKSASVog=XkX=+cXCt5r3ew@mail.gmail.com>
 <20181218151258.38796e76@redhat.com>
In-Reply-To: <20181218151258.38796e76@redhat.com>
From:   Dmitry Vyukov <dvyukov@google.com>
Date:   Tue, 18 Dec 2018 17:05:41 +0100
Message-ID: <CACT4Y+ZQKfCgPoekJLfLLezHgs8CUAwHZgZX063fPJL=xqjEqA@mail.gmail.com>
Subject: Re: WARNING in __rcu_read_unlock
To:     Stefano Brivio <sbrivio@redhat.com>
Cc:     Eric Dumazet <eric.dumazet@gmail.com>,
        Arjan van de Ven <arjan@linux.intel.com>,
        "Paul E. McKenney" <paulmck@linux.ibm.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Josh Triplett <josh@joshtriplett.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@kernel.org>,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
        netdev <netdev@vger.kernel.org>,
        Cong Wang <xiyou.wangcong@gmail.com>,
        Xin Long <lucien.xin@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Dec 18, 2018 at 3:13 PM Stefano Brivio <sbrivio@redhat.com> wrote:
>
> [Dropping syzbot from Cc:]
>
> On Tue, 18 Dec 2018 14:26:00 +0100
> Dmitry Vyukov <dvyukov@google.com> wrote:
>
> > On Tue, Dec 18, 2018 at 1:40 PM Stefano Brivio <sbrivio@redhat.com>
> > 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: <name>
>         <description>
>
> 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.


I hope we can solve these technical problems without imposing more
work onto humans. And just run all repros.
Besides the fact that it's just not good to ask people to do what
machines can do, _very_ few people will use these new tags.
Potentially we will have just this repro marked by you :)


> > 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?

That's the problem. Once we need them we will need to build and copy
to the target machine the exact syzkaller revision used to produce
that repro. So if we will test 10K repros, we will need 10K builds and
binaries copied.