Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx> writes:
> Hey,
>
> Op 25-09-12 09:05, Eric W. Biederman schreef:
>> Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx> wrote:
>>
>>> Hey,
>>>
>>> Op 25-09-12 05:39, Eric W. Biederman schreef:
>>>> Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx> writes:
>>>>
>>>>> This reverts commit ee3efa91e240f513898050ef305a49a653c8ed90.
>>>>>
>>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx>
>>>>>
>>>>> My thread about the regression seemed to have been ignored, so I can
>>> only
>>>>> conclude nobody objects against a full revert of this patch.
>>>>>
>>>>> My testcase is simply booting through netboot with / and ~/nfs as
>>> separate
>>>>> nfs filesystems, then doing 'ls ~/nfs' followed by 'ls ~' in a
>>> gnome-terminal
>>>>> window, then I get:
>>>> Do I read your description correctly: Without using a bind mount you
>>>> have the same nfs filesystem mounted on / and on ~/nfs?
>>>>
>>>> Something is definitely off with your configuration but if to work
>>> you
>>>> need to move mount points around then that something seems much
>>> deeper
>>>> than the __d_unalias change.
>>>>
>>>> What filesystems do you have mounted where?
>>>>
>>> / is a nfs filesystem, ~/nfs is a different nfs filesystem.
>> Are both filesystems on the same server?
>>
>> Are the two filesystems distinct filesystem on the server?
>>
>> Unless there is duplication of something somewhere the d_unalias code should not trigger.
>
> They're both on the same physical filesystem on the server, but unique exports:
> /home/mlankhorst/nfs *(no_subtree_check,insecure,rw,all_squash,anonuid=1000,anongid=1000)
> /home/mlankhorst/kvm/quantal-amd64 *(no_subtree_check,insecure,rw,no_root_squash)
Modern NFS does some interesting things with disconnected roots and the
like. I don't think it should be connecting those two filesytems
together because there are no overlapping directories.
I really don't get why using one filesystem causes confusion in the other.
> Rootfs is mounted by the kernel itself, I used a custom init script to mount /lib/modules
> early on:
>
> mount -t nfs -o nolock,vers=3 192.168.1.128:/home/mlankhorst/nfs /home/mlankhorst/nfs &&
> mkdir -p /lib/modules/$(uname -r)/kernel &&
> mount --bind /home/mlankhorst/nfs/linux /lib/modules/$(uname -r)/kernel &&
> ([ -f /lib/modules/$(uname -r)/modules.symbols ] || depmod)
>
> exec /sbin/init
Could you try the following patch? This should report what directories
cannot be renamed because one of them is a mount point and it gives some
real insight into what is going on.
Eric
diff --git a/fs/dcache.c b/fs/dcache.c
index 8086636..193b7be 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -2374,6 +2374,7 @@ struct dentry *d_ancestor(struct dentry *p1, struct dentry *p2)
return NULL;
}
+static char *__dentry_path(struct dentry *dentry, char *buf, int buflen);
/*
* This helper attempts to cope with remotely renamed directories
*
@@ -2401,6 +2402,18 @@ static struct dentry *__d_unalias(struct inode *inode,
goto out_err;
m2 = &alias->d_parent->d_inode->i_mutex;
out_unalias:
+#if 1
+ if (d_mountpoint(alias)) {
+ static char buf1[8192];
+ static char buf2[8192];
+ char *alias_name, *dentry_name;
+ alias_name = __dentry_path(alias, buf1, sizeof(buf1));
+ dentry_name = __dentry_path(dentry, buf2, sizeof(buf2));
+
+ printk(KERN_DEBUG "%s: %s -> %s\n",
+ __func__, alias_name, dentry_name);
+ }
+#endif
if (likely(!d_mountpoint(alias))) {
__d_move(alias, dentry);
ret = alias;
--
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
