From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752646AbcCBGi3 (ORCPT ); Wed, 2 Mar 2016 01:38:29 -0500 Received: from mail-pf0-f174.google.com ([209.85.192.174]:33353 "EHLO mail-pf0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751652AbcCBGi1 (ORCPT ); Wed, 2 Mar 2016 01:38:27 -0500 Date: Wed, 2 Mar 2016 14:37:18 +0800 From: Boqun Feng To: Peter Zijlstra Cc: "Paul E. McKenney" , linux-kernel@vger.kernel.org, Ingo Molnar , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , sasha.levin@oracle.com Subject: Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical sections Message-ID: <20160302063718.GA5721@fixme-laptop.cn.ibm.com> References: <1455602265-16490-1-git-send-email-boqun.feng@gmail.com> <20160225143243.GP6357@twins.programming.kicks-ass.net> <20160225153724.GL3522@linux.vnet.ibm.com> <20160226030627.GA2431@fixme-laptop.cn.ibm.com> <20160226112521.GZ6356@twins.programming.kicks-ass.net> <20160229011220.GA1583@fixme-laptop.cn.ibm.com> <20160229124318.GM6356@twins.programming.kicks-ass.net> <20160301093242.GA29874@fixme-laptop.cn.ibm.com> <20160301095707.GP6356@twins.programming.kicks-ass.net> <20160301100134.GW6375@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <20160301100134.GW6375@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 01, 2016 at 11:01:34AM +0100, Peter Zijlstra wrote: > On Tue, Mar 01, 2016 at 10:57:07AM +0100, Peter Zijlstra wrote: > > On Tue, Mar 01, 2016 at 05:32:42PM +0800, Boqun Feng wrote: > > > > One could for example allow something like: > > > >=20 > > > > rcu_read_lock(); > > > > rcu_annotate(&var->field); > > > >=20 > > > > foo(); > > > >=20 > > > > rcu_read_unlock(); > > > >=20 > > > > As an alternative to the syntax suggested by Ingo. This would allow > > > > keeping the existing rcu_read_lock() signature so you don't have to > > > > force update the entire kernel at once, while also (easily) allowing > > > > multiple variables. Like: > > > >=20 > > > > rcu_read_lock(); > > > > rcu_annotate(&var->field); > > > > rcu_annotate(&var2->field2); > > > >=20 > > > > You can then have a special rule that if a particular RCU section h= as an > > > > annotation, any rcu_dereference() not matched will field a warning.= If > > > > the annotation section is empty, nothing. > > > >=20 > > >=20 > > > Good idea! but I don't think annotating a field in C language is easy, > > > I will try to see what we can get. Do you have something already in y= our > > > mind? > >=20 > > No, didn't really think about that :-/ The most restrictive version is > > taking the absolute address, but that would make things like actual data > > structures impossible. >=20 Another problem of taking the absolute address is the address may change =66rom rcu_annotate() to rcu_dereference() for example: rcu_read_lock(); rcu_annotate(&var->field); // in another thread var =3D new_var; =09 // the address of var->field is different now. rcu_dereference(var->field); rcu_read_unlock(); > So the thing with locks is they get a struct lockdep_map added, in which > we store all kinds of useful. But I don't think we cannot add a similar > structure to each and every RCU dereferencable (is that a word?) > variable. >=20 Well, some of them have rcu_head, but not all.. so you're right. >=20 I come up with something you may not like ;-) , which is taking the strings of the expressions, for example: rcu_read_lock(); rcu_annotate(var->field); // "var->field" is added for=20 // the current section rcu_dereference(var->field); // OK, because the expression // "var->field" is annotated. rcu_dereference(var->field2); // Not OK, because the // expression "var->field2" is // not annotated, nor is any of // its suffix. rcu_annotate(field3); // "field3" is added for the // current section =09 rcu_dereference(var2->field3); // OK, because the suffix // "field3" is annotated. rcu_read_unlock(); I think this is more accurate than taking the absolute address because the address changing situations exist. So.. thoughts? Regards, Boqun --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJW1ooWAAoJEEl56MO1B/q4IzIIALCwuw6ZAsWSMGQ6/q3HGEtk VNfCpVUX0j9Un/Y86fXBVo3A2UuFFuBdJr6zs1w0x9ZpCbdQwsgb06Zo+Xxxh4Hd HuO+f2hvorAC18kp322T59aY77fSdfx5QIxmtOqEbbPbLluAFl23PWSMESqHr64t U3p7MVKDjd5P1gXVf2ojcoSEYPBcJ5YXg40MeOtJrpD1+z93cfJ1pPam3DIiCIMi 6Tjo+bZmhhG2UiamRGB1kWxm24zLjUh0KX286FK+IxVSO/kW+TZLFEOAbfUInM5H n87IFCqyJeuaRpVqcn/jTXI7Svhtwky/g8imayisNx4g0vzb19mAT68JJloLL6c= =uFZz -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD--