From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753219AbcBZDHG (ORCPT ); Thu, 25 Feb 2016 22:07:06 -0500 Received: from mail-pf0-f182.google.com ([209.85.192.182]:36365 "EHLO mail-pf0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751338AbcBZDHE (ORCPT ); Thu, 25 Feb 2016 22:07:04 -0500 Date: Fri, 26 Feb 2016 11:06:27 +0800 From: Boqun Feng To: "Paul E. McKenney" Cc: Peter Zijlstra , 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: <20160226030627.GA2431@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <20160225153724.GL3522@linux.vnet.ibm.com> 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 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 25, 2016 at 07:37:24AM -0800, Paul E. McKenney wrote: > On Thu, Feb 25, 2016 at 03:32:43PM +0100, Peter Zijlstra wrote: > > On Tue, Feb 16, 2016 at 01:57:39PM +0800, Boqun Feng wrote: > > > As a characteristic of RCU, read-side critical sections have a very > > > loose connection with rcu_dereference()s, which is you can only be su= re > > > about an rcu_dereference() might be called in some read-side critical > > > section, but if code gets complex, you may not be sure which read-side > > > critical section exactly, this might be also an problem for some other > > > locking mechanisms, that is the critical sections protecting data and > > > the data accesses protected are not clearly correlated. > > >=20 > > > In this series, we are introducing LOCKED_ACCESS framework and based = on > > > which, we implement the RCU_LOCKED_ACCESS functionality to give us a > > > clear hint: which rcu_dereference() happens in which RCU read-side > > > critical section.=20 > > >=20 > > > After this series applied, and if CONFIG_RCU_LOCKED_ACCESS=3Dy, the p= roc > > > file /proc/locked_access/rcu will show all relationships collected so > > > far for rcu_read_lock() and their friends and rcu_dereference*(). > >=20 > > But why !? What does this bring us, why do I want to even look at these > > patches? >=20 > There were some complaints about the difficulty of figuring out what > was being protected by a given rcu_read_lock() in cases where the > corresponding rcu_dereference() is several function calls down, and > especially in cases where the function calls are via pointers. > These cases show up in a number of places, perhaps most prominently > in networking. >=20 > Boqun's patches therefore use lockdep to make an association between > each rcu_dereference() and the rcu_read_lock() protecting it. >=20 Yes, this patch is aiming to provide some information about this, actually the background of this patchset is a discussion between Ingo and Paul last year: http://lkml.kernel.org/g/20150414102505.GA13015@gmail.com In that discussion, Ingo gave one example about how hard it is to figure out what a RCU read-side critical section is protecting. Ingo's proposal of solving this problem was to add an extra parameter for RCU related primitives, however, Paul seemed to have concerns about that approach, because there were many RCU users' code that would need to be modified and there were corner cases where the one extra parameter was not enough or not necessary. Therefore I tried to figure out a way for making the association of rcu_dereference() and rcu_read_lock() automatically without the modification of code of the RCU users. That's how this patchset comes. Regards, Boqun > Seem reasonable, or were the complaints just a flash in the pan? >=20 > Thanx, Paul >=20 --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJWz8EuAAoJEEl56MO1B/q4nm8H/jXwyyxks2ZmaWs1p/hK5PIN YQ5/Gus5mzjrdk+XtICF02LljY0/thGfmYzUacAKJY+0/tTanBpI6BqUAzFPdDyj 6BijkDjHHO4zYzauCwxuTH1RJlEi5Jghxh/5QGoHfLuGNjFm0EPeK5VKXotzCAY1 cFSXZEaxAF0eseNItPZGUoEeODzha+cXf593EBL1qV2x0J2r1DumbAjCZKu02KUr NgAgGp6H5ZqUbOBuglge6nqyNOax+aSMLilQJN5t99F0FQ93iH93fqnuo3XwhkN9 Ng6eDD+9GttpVuxbShgX39Hw5PLcA/zxe06IKIX/gQzVNaMrKnC26T7np4kDcx8= =pHSl -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF--