"J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes:
> On Thu, Feb 13, 2014 at 03:45:16PM -0800, Eric W. Biederman wrote:
>> "J. Bruce Fields" <bfields@xxxxxxxxxxxx> 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.
The nfs client also has the case where it uses DISCONNECTED dentries for
directories that are not root on the server. Which seems very similiar
to the btrfs case.
Usually I would expect some of these things to pass through
d_materialise_unique and become connected. But I don't know much about
the nfsd usage and how things connected.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
