From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: WARNING in __rcu_read_unlock Date: Tue, 18 Dec 2018 06:02:58 -0800 Message-ID: <20181218140258.GQ4170@linux.ibm.com> References: <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> Reply-To: paulmck@linux.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Stefano Brivio , Eric Dumazet , Arjan van de Ven , syzbot , Andrew Morton , Josh Triplett , LKML , Ingo Molnar , syzkaller-bugs , netdev , Cong Wang , Xin Long To: Dmitry Vyukov Return-path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:53764 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726419AbeLRODE (ORCPT ); Tue, 18 Dec 2018 09:03:04 -0500 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wBIDsBif040090 for ; Tue, 18 Dec 2018 09:03:03 -0500 Received: from e11.ny.us.ibm.com (e11.ny.us.ibm.com [129.33.205.201]) by mx0a-001b2d01.pphosted.com with ESMTP id 2peyprqt0q-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 18 Dec 2018 09:03:02 -0500 Received: from localhost by e11.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 18 Dec 2018 14:03:01 -0000 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Dec 18, 2018 at 02:26:00PM +0100, Dmitry Vyukov wrote: > On Tue, Dec 18, 2018 at 1:40 PM Stefano Brivio wrote: > > > > On Tue, 18 Dec 2018 09:49:17 +0100 > > Dmitry Vyukov wrote: > > > > > On Tue, Dec 18, 2018 at 12:18 AM Stefano Brivio wrote: > > > > > > > > On Mon, 17 Dec 2018 16:53:36 +0100 > > > > Dmitry Vyukov wrote: > > > > > > > > > On Mon, Dec 17, 2018 at 4:24 PM Stefano Brivio wrote: > > > > > > > > > > > > On Mon, 17 Dec 2018 06:57:35 -0800 > > > > > > Eric Dumazet wrote: > > > > > > > > > > > > > Might be cause by commit b8a51b38e4d4dec3e379d52c0fe1a66827f7cf1e > > > > > > > fou, fou6: ICMP error handlers for FoU and GUE > > > > > > > > > > > > This: > > > > > > > > > > > > diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c > > > > > > index 0d0ad19ecb87..20a6de26d146 100644 > > > > > > --- a/net/ipv4/fou.c > > > > > > +++ b/net/ipv4/fou.c > > > > > > @@ -1008,6 +1008,9 @@ static int gue_err_proto_handler(int proto, struct sk_buff *skb, u32 info) > > > > > > { > > > > > > const struct net_protocol *ipprot = rcu_dereference(inet_protos[proto]); > > > > > > > > > > > > + if (ipprot == IPPROTO_UDP) > > > > > > + return -EINVAL; > > > > > > + > > > > > > if (ipprot && ipprot->err_handler) { > > > > > > if (!ipprot->err_handler(skb, info)) > > > > > > return 0; > > > > > > > > > > > > should fix the issue, but I still have to run tests and make sure we > > > > > > don't hit similar cases. > > > > > > > > > > Please don't forget to add a regression test for it too ;) > > > > > > > > Where would you suggest to add this? The only selftest that goes > > > > > > I dunno. But there must be some place for such tests, right? > > > > Not as far as I know. The selftests checking this path, by design, only > > use supported configurations, they don't forge packets. > > > > 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... > > > > Eric, Cong, Xin, as you also recently fixed a nice deal of similar cases > > reported by syzbot, what do you think? Did you ever feel the need to > > turn a syzbot reproducer into a regression test case? > > > > > > through this path currently is net/pmtu.sh, but as configuration of an > > > > actual UDP-in-GUE tunnel is currently not supported, I would really > > > > need to forge that specific packet, so that doesn't seem to be a good > > > > fit. > > > > > > > > Won't syzbot add this to some list of reproducers that are checked in > > > > the future? > > > > > > It won't. Also fuzzing is complementary to testing, not a replacement: > > > > Indeed, but that doesn't mean we need to limit the potential of fuzzing > > because "it's not testing". It can be used to check for regressions, > > too, especially in these cases. > > > > > https://twitter.com/dvyukov/status/1074719682962358272 > > > > Now, I'm extremely thankful for the work you're doing and especially > > for finding this subtle condition with syzbot, but this is quite > > inaccurate. To be exposed to this issue, the user would need to > > have the fou module loaded (it won't autoload), which is used quite > > rarely, and, on top of that, have a UDP tunnel configured. It wouldn't > > have been the kind of "evil packet crashes the internet" scenario you > > were dreaming of ;) > > Okay, I see. Full bug assessment is hard. I mess it both ways for > different bugs. > But I did not claim that it does not require some setup :) > And maybe there is somebody important on the internet that uses such > setup. Who knows. Black hats, if no one else. ;-) Thanx, Paul