Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932903Ab1CWWpr (ORCPT ); Wed, 23 Mar 2011 18:45:47 -0400 Received: from cantor.suse.de ([195.135.220.2]:56723 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755197Ab1CWWpq (ORCPT ); Wed, 23 Mar 2011 18:45:46 -0400 Subject: Re: [PATCH 02/36] scsi,rcu: convert call_rcu(fc_rport_free_rcu) to kfree_rcu() From: James Bottomley To: paulmck@linux.vnet.ibm.com Cc: Robert Love , Lai Jiangshan , Ingo Molnar , Jens Axboe , Neil Horman , "David S. Miller" , Alexey Kuznetsov , "Pekka Savola (ipv6)" , James Morris , Hideaki YOSHIFUJI , Patrick McHardy , Eric Dumazet , Stephen Hemminger , Tejun Heo , Jarek Poplawski , "linux-kernel@vger.kernel.org" , "devel@open-fcoe.org" , "linux-scsi@vger.kernel.org" , "netdev@vger.kernel.org" In-Reply-To: <20110323222456.GC2322@linux.vnet.ibm.com> References: <4D82D071.5020703@cn.fujitsu.com> <4D82D3FF.2080303@cn.fujitsu.com> <4D82D45A.30102@cn.fujitsu.com> <1300814913.19083.427.camel@fritz> <20110323065014.GU2322@linux.vnet.ibm.com> <1300889151.15899.4.camel@mulgrave.site> <20110323222456.GC2322@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 23 Mar 2011 17:45:32 -0500 Message-ID: <1300920332.15899.45.camel@mulgrave.site> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1943 Lines: 48 On Wed, 2011-03-23 at 15:24 -0700, Paul E. McKenney wrote: > On Wed, Mar 23, 2011 at 09:05:51AM -0500, James Bottomley wrote: > > On Tue, 2011-03-22 at 23:50 -0700, Paul E. McKenney wrote: > > > The kfree_rcu() definition is as > > > follows: > > > > > > #define kfree_rcu(ptr, rcu_head) \ > > > __kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head)) > > > > Isn't this one of those cases where the obvious use of the interface is > > definitely wrong? > > > > It's also another nasty pseudo C prototype. I know we do this sort of > > thing for container_of et al, but I don't really think we want to extend > > it. > > > > Why not make the interface take a pointer to the embedding structure and > > one to the rcu_head ... that way all pointer mathematics can be > > contained inside the RCU routines. > > Hello, James, > > If you pass in a pair of pointers, then it is difficult for RCU to detect > bugs where the two pointers are unrelated. Yes, you can do some sanity > checks, but these get cumbersome and have corner cases where they can > be fooled. In contrast, Lai's interface allows the compiler to do the > needed type checking -- unless the second argument is a field of type > struct rcu_head in the structure pointed to by the first argument, the > compiler will complain. > > Either way, the pointer mathematics are buried in the RCU API. > > Or am I missing something here? No ... I like the utility ... I just dislike the inelegance of having to name a structure element in what looks like a C prototype. I can see this proliferating everywhere since most of our reference counting release callbacks basically free the enclosing object ... James -- 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/