From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: find_fh_dentry returned a DISCONNECTED directory Date: Thu, 13 Feb 2014 22:30:32 -0500 Message-ID: <20140214033030.GC21982@fieldses.org> References: <20140213212701.GB21982@fieldses.org> <8738jm1ss3.fsf@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: jbacik@fb.com, linux-fsdevel@vger.kernel.org To: "Eric W. Biederman" Return-path: Received: from fieldses.org ([174.143.236.118]:57572 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751089AbaBNDah (ORCPT ); Thu, 13 Feb 2014 22:30:37 -0500 Content-Disposition: inline In-Reply-To: <8738jm1ss3.fsf@xmission.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Feb 13, 2014 at 03:45:16PM -0800, Eric W. Biederman wrote: > "J. Bruce Fields" writes: > > > Yesterday you passed on a report of this printk from nfsdfh.c firing: > > > > printk("nfsd: find_fh_dentry returned a DISCONNECTED directory: %pd2\n", > > dentry); > > > > I think the dentry probably comes from the FILEID_ROOT case of: > > > > if (fileid_type == FILEID_ROOT) > > dentry = dget(exp->ex_path.dentry); > > else { > > dentry = exportfs_decode_fh(exp->ex_path.mnt, fid, > > data_left, fileid_type, > > nfsd_acceptable, exp); > > } > > > > In that case the dentry was found using ordinary filesystem lookups, so > > doesn't go through the same DISCONNECTED-clearing logic as in the case > > of lookups by filehandle. > > > > Probably they have an export root that's not a filesystem root, and the > > lookups happened in the right order? > > > > I suspect that's fine, and that the printk is just stupid, but maybe we > > should clear DISCONNECTED when possible on normal lookups. The > > following is my attempt, though I'm not sure if d_alloc is the right > > place to do this. In any case it might help confirm this is what's > > happening. > > > > So if you pass along this patch to the person who was seeing that printk > > I'd be interested in the results. > > I have been reading through the dentry code for other reasons and your > patch definitely won't change anything. __d_alloc sets d_flags = 0. > Therefore d_alloc always returns with d_flags == 0. You're right, of course. I wasn't thinking straight. So the only dentries with DISCONNECTED set are those created with d_obtain_alias, which is normally only used when you're looking up by filehandle. Except btrfs has a weird use in get_default_root(). So maybe they were running into the dentry that created? So btrfs should probably be using something else, I'm not sure what. --b.