Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754042AbYHBAET (ORCPT ); Fri, 1 Aug 2008 20:04:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751819AbYHBAEL (ORCPT ); Fri, 1 Aug 2008 20:04:11 -0400 Received: from bombadil.infradead.org ([18.85.46.34]:39938 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751813AbYHBAEK (ORCPT ); Fri, 1 Aug 2008 20:04:10 -0400 Subject: Re: [patch 01/15] Kernel Tracepoints From: Peter Zijlstra To: paulmck@linux.vnet.ibm.com Cc: Mathieu Desnoyers , akpm@linux-foundation.org, Ingo Molnar , linux-kernel@vger.kernel.org, Masami Hiramatsu , "Frank Ch. Eigler" , Hideo AOKI , Takashi Nishiie , Steven Rostedt , Alexander Viro , Eduard - Gabriel Munteanu In-Reply-To: <20080801211020.GQ14851@linux.vnet.ibm.com> References: <1216108237.12595.122.camel@twins> <20080715132543.GB20037@Krystal> <1216130356.12595.184.camel@twins> <20080715142710.GC20037@Krystal> <1216132928.12595.201.camel@twins> <20080715152224.GE20037@Krystal> <1216135902.12595.214.camel@twins> <20080715160813.GB27626@Krystal> <1216139149.12595.224.camel@twins> <20080715165122.GB30082@Krystal> <20080801211020.GQ14851@linux.vnet.ibm.com> Content-Type: text/plain Date: Sat, 02 Aug 2008 02:03:57 +0200 Message-Id: <1217635437.9016.29.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1367 Lines: 32 On Fri, 2008-08-01 at 14:10 -0700, Paul E. McKenney wrote: > Yeah, I was thinking in terms of rcu_dereference() working with both > rcu_assign_pointer() and an as-yet-mythical rcu_assign_index(). Perhaps > this would be a good time to get better names: > > Current: rcu_assign_pointer() rcu_dereference() > New Pointers: rcu_publish_pointer() rcu_subscribe_pointer() > New Indexes: rcu_publish_index() rcu_subscribe_index() Is it really worth the effort, splitting it out into these two cases? > And, while I am at it, work in a way of checking for either being in > the appropriate RCU read-side critical section and/or having the > needed lock/mutex/whatever held -- something I believe PeterZ was > prototyping some months back. Yeah - I have (bitrotted a bit, but should be salvageable) lockdep annotations for rcu_dereference(). The problem with them is the huge amount of false positives.. Take for example the Radix tree code, its perfectly fine to use the radix tree code without RCU - say you do the old rwlock style, still it uses rcu_dereference(). I never figured out a suitable way to annotate that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/