From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [RFC] lustre treatment of dentry->d_name Date: Wed, 22 Oct 2014 03:50:26 +0100 Message-ID: <20141022025026.GW7996@ZenIV.linux.org.uk> References: <20141021011346.GP7996@ZenIV.linux.org.uk> <20141021040210.GR7996@ZenIV.linux.org.uk> <01AC4DD5-3DA1-4C98-BED3-B009AAF8C951@intel.com> <20141021211710.GV7996@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Hammond, John" , "linux-fsdevel@vger.kernel.org" , "Dilger, Andreas" To: "Drokin, Oleg" Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:59904 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751267AbaJVCu3 (ORCPT ); Tue, 21 Oct 2014 22:50:29 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Oct 22, 2014 at 01:48:48AM +0000, Drokin, Oleg wrote: > Ah! I see now. > We do the "pick alias from a list" for everything, not just for the directories. > So that difference is still missing and as such there is a fear if we > convert to d_splice_alias in its current form, dcache would explode > from all the gazillions of invalid and unhashed dentries we produce during > operations. Interesting... Where do those gazillions come from? AFAICS, your ->d_revalidate() does that only when you get LOOKUP_OPEN | LOOKUP_CREATE in flags, i.e. on the final component of pathname at open() with O_CREAT. Hmm... So basically you are trying to force them into ->atomic_open() codepath? Fine, but... why not simply have ->open() pick what hadn't gone through ->atomic_open()? Check what nfs4_file_open() is doing; if you find out that the damn thing *was* stale (i.e. that you really need a different inode, etc.), it's not a problem - d_drop() and return -EOPENSTALE; VFS will repeat lookups. Note that do_dentry_open() doesn't strip O_CREAT from file->f_flags until after return from ->open(). So you can see O_CREAT in ->open() just fine - this case is easy to distinguish there. Incidentally, why the hell do you have separate ll_revalidate_nd() and ll_revalidate_dentry()? I realize that it'll be inlined by compiler (the only call of the latter is tail-call with identical arguments from the former), but... Another nasty question: is d_need_statahead() safe in RCU pathwalk mode? When are ll_dentry_data and ll_inode_info freed? Ditto for ->lli_sai. Sure, actual freeing of struct inode and struct dentry is RCU-delayed, but from the quick glance it seems that freeing those guys isn't...