Re: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]

[David Howells <dhowells@redhat.com>]

Andrew Morton <akpm@osdl.org> wrote:

> The funny-looking dentries in /net/bix have gone away.
> 
> But `ls -l /net/bix/usr/src' doesn't mount bix:/usr/src.

Yes, that I believe is due to the automounter program combined with that
optimisation in the NFS client code.  *readdir* fixes the falsely negative
dentry, but only if you _do_ a readdir of the parent directory, and only then
if you read enough of the directory to locate the dodgy dentry.

This is normally only a problem if SELinux aborts the mkdir operation between
calling the filesystem's lookup() op and the filesystem's mkdir() op, if the
filesystem is written - as NFS is - to assume the the lookup() op _will_ be
followed by a call to the mkdir() op whatever happens.  Unfortunately, with
SELinux sticking its foot in the way, this no longer holds true, and the
initial lookup _must_ properly instantiate the dentry it is given - and that
means it must query the server in such a case.

That said, that will likely prevent autofs from being able to create arbitrary
directories if the underlying security constraints don't let it.

There is another problem with autofs arbitrarily creating directory dentries
in this manner: the automount program doesn't know whether the directory it is
creating corresponds to a directory on the server - or whether it corresponds
to a symbolic link...  The server _must_ be queried.

So, I think:

 (1) I have to change my patch again, and that I have to make nfs_lookup()
     unconditionally query the server (comments Trond?), and

 (2) Ian has to patch the automounter to not attempt to mount undermounts
     automatically - with the new in-NFS-client automounting code, this should
     be unnecessary, except for when the an intervening directory is
     inaccessible, and I'm not sure what you can do about that (Ian? Trond?)

David

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/