On Mon, Sep 26, 2011 at 2:31 PM, Trond Myklebust
<Trond.Myklebust@xxxxxxxxxx> wrote:
>
> A bind mount doesn't actually want us to set up OPEN state on the NFSv4
> server and return a fully initialised 'struct file' in the struct
> nameidata. If it did, we would already have set the LOOKUP_OPEN flag
> together with the accompanying open intent structure in the struct
> nameidata.
>
> Ditto for the quotactl().
Umm. As far as I can see, adding LOOKUP_OPEN doesn't actually even
*do* what you claim.
The whole "allocate struct file in struct nameidata" happens in
path_openat(), it doesn't happen in the normal path creation
(do_path_lookup() and friends). The only thing NFS does with
LOOKUP_OPEN is to check whether it needs to do a revalidate
regardless.
But even more importantly than your apparent confusion about filling
in the 'nameidata.intent' fields, even *if* we were to do unnecessary
filp allocations etc (which we don't do, as mentioned), from a user
standpoint, what would be the actual downside?
It would be extra work for a (very rare) operation, but compared to
the known downside that is LOOKUP_FOLLOW and auto-mounting when we
shouldn't, even that hypothetical downside seems pretty benign,
doesn't it?
In other words, what I don't understand is how you seem to be totally
happy ignoring the known problems with LOOKUP_FOLLOW, but LOOKUP_OPEN
is some monster thing that you don't want to deal with.
WHY?
Linus
PS. That said, looking at the *cifs* code, it seems to do some nasty
things on LOOKUP_OPEN, and assumes that it always has a 'file'
pointer. Sad. That might actually argue for another flag, or
alternatively for just fixing CIFS.
--
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
