Ian Kent <raven@xxxxxxxxxx> wrote:
> But the other users of the vfs-automount didn't behave this way before
> the vfs-automount changes.
That's a very good point. Prior to my d_automount() patches, NFS, AFS and, I
think, CIFS used strict symlink rules for when to automount because the
automounting was done by a directory with a ->follow_link() op. Therefore,
stat() automounted and lstat() didn't.
Autofs, on the other hand took care to suppress automounting on stat() too.
My d_automount() patches had two purposes, in order of importance:
(1) Simplify the automount procedure in the kernel by giving it formal VFS
support, and thus getting rid of directories with follow_link() ops.
(2) Make the automount semantics consistent.
So my original patches are somewhat at fault here. I broke autofs's handling
of stat(), getxattr() and kept that of NFS, AFS and CIFS. Miklos's patch
simply flips the regression the other way.
The only fault I've had reported against my original patches in this respect is
with ls, and that's fixed in userspace upstream now (libacl was using getxattr
when it should've been using lgetxattr). It has been mentioned that nautilus
(I think it was) may also broken - which makes sense as it's a file manager.
The only fault I've had reported against Miklos's patch is the NFS4 pathwalk
during mount.
Having thought it over some more, I'm leaning towards reverting Miklos's patch,
removing the do we/don't we logic from follow_automount() (or simplifying it)
and having the syscalls suppy the LOOKUP_NO_AUTOMOUNT flag as appropriate -
whatever is meant by 'appropriate'.
I'm also okay with requiring userspace to be fixed up, but I can also see the
arguments against that.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
