From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Brown Subject: Re: Why do we pass in a directory and a dentry to lookup() and rename() Date: Tue, 28 Dec 2010 20:46:19 +1100 Message-ID: <20101228204619.4f9e1722@notabene.brown> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Al Viro , linux-fsdevel@vger.kernel.org To: "Theodore Ts'o" Return-path: Received: from cantor.suse.de ([195.135.220.2]:42171 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751885Ab0L1Jq2 (ORCPT ); Tue, 28 Dec 2010 04:46:28 -0500 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, 26 Dec 2010 16:45:51 -0500 "Theodore Ts'o" wrote: > In the inode operations functions lookup() and rename(): > > struct dentry * (*lookup)(struct inode *inode, > struct dentry *dentry, > struct nameidata *nd); > > int (*rename)(struct inode *old_dir, struct dentry *old_dentry, > struct inode *new_dir, struct dentry *new_entry); > > ... is the fact that we pass in the inode superfluous? > > i.e., it looks like in all cases one can obtain the inode by looking at > dentry->d_parent. Or am I missing something? > I'd guess that it is "historical reasons". Some times it isn't safe to de-reference ->d_parent without extra locking (via dget_parent) so there could be cases where passing an already-ref-counted pointer might be cleaner, but during lookup and rename there must be sufficient locking so that ->d_parent cannot change. So all you could gain by passing the pointer separately is avoiding a single memory reference. As d_parent is almost certainly in cache when these are called, that would not be a big gain. It might be worth checking that the code doesn't get bigger if you drop the arg and use ->d_parent instead, but assuming it doesn't (which seems likely), I would agree that passing the parent inode explicitly is unnecessary. NeilBrown