From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752226AbdJKPqB (ORCPT ); Wed, 11 Oct 2017 11:46:01 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:33707 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750831AbdJKPqA (ORCPT ); Wed, 11 Oct 2017 11:46:00 -0400 Date: Wed, 11 Oct 2017 08:45:32 -0700 From: "Paul E. McKenney" To: Paolo Abeni Cc: linux-kernel@vger.kernel.org, Josh Triplett , Steven Rostedt , "David S. Miller" , Eric Dumazet , Hannes Frederic Sowa , netdev@vger.kernel.org Subject: Re: [PATCH 0/4] RCU: introduce noref debug Reply-To: paulmck@linux.vnet.ibm.com References: <20171006133436.GY3521@linux.vnet.ibm.com> <1507302609.2793.16.camel@redhat.com> <20171006163414.GC3521@linux.vnet.ibm.com> <1507567992.21825.9.camel@redhat.com> <20171011040225.GU3521@linux.vnet.ibm.com> <1507733436.2487.32.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1507733436.2487.32.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17101115-0044-0000-0000-0000039E101B X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007878; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000236; SDB=6.00929645; UDB=6.00467914; IPR=6.00709916; BA=6.00005634; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017491; XFM=3.00000015; UTC=2017-10-11 15:45:35 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17101115-0045-0000-0000-000007CD11B8 Message-Id: <20171011154532.GD3521@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-11_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710110217 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 11, 2017 at 04:50:36PM +0200, Paolo Abeni wrote: > On Tue, 2017-10-10 at 21:02 -0700, Paul E. McKenney wrote: > > Linus and Ingo will ask me how users decide how they should set that > > additional build flag. Especially given that if there is code that > > requires non-strict checking, isn't everyone required to set up non-strict > > checking to avoid false positives? Unless you can also configure out > > all the code that requires non-strict checking, I suppose, but how > > would you keep track of what to configure out? > > I'm working to a new version using a single compile flag - without > additional strict option. > > I don't know of any other subsytem that stores rcu pointer in > datastructures for a longer amount of time. That having said, I wonder > if the tests should completely move to the networking subsystem for the > time being. The Kconfig option would thus be called NET_DEBUG or > something along the lines. For abstraction it would be possible to add > an atomic_notifier_chain to the rcu_read/unlock methods, where multiple > users or checkers could register for. That way we keep the users > seperate from the implementation for the cost of a bit more layering > and more indirect calls. But given that this will anyway slow down > execution a lot, it will anyway only be suitable in > testing/verification/debugging environments. I like this approach. And if it does a good job of finding networking bugs over the next year or so, I would be quite happy to consider something for all RCU users. > > OK. There will probably be some discussion about the API in that case. > > I'll drop noref parameter, the key will became mandatory - the exact > position of where the reference of RCU managed object is stored. In the > case of noref dst it is &skb->_skb_refdst. With this kind of API it > should suite more subsystems. Interesting. Do you intend to allow rcu_track_noref() to refuse to record a pointer? Other than for the array-full case. > > True enough. Except that if people were good about always clearing the > > pointer, then the pointer couldn't leak, right? Or am I missing something > > in your use cases? > > This is correct. The dst_entry checking in skb, which this patch series > implements there are strict brackets in the sense of skb_dst_set, > skb_dst_set_noref, skb_dst_force, etc., which form brackets around the > safe uses of those dst_entries. This patch series validates that the > correct skb_dst_* functions are being called before the sk_buff leaves > the rcu protected section. Thus we don't need to modify and review a > lot of code but we can just patch into those helpers already. Makes sense. Those willing to strictly bracket uses gain some debug assist. > > Or to put it another way -- have you been able to catch any real > > pointer-leak bugs with thister-leak bugs with this? The other RCU > > debug options have had pretty long found-bug lists before we accepted > > them. > > There have been two problems found so far, one is a rather minor one > while the other one seems like a normal bug. The patches for those are > part of this series (3/4 and 4/4). I agree that you have started gathering evidence and that the early indications are positive, if quite mildly so. If this time next year there are a few tens of such bugs found, preferably including some serious ones, I would very likely look favorably on pulling this in to allow others to use it. Thanx, Paul