On Mon, 2011-09-26 at 15:24 -0700, Linus Torvalds wrote: > 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. Please see the 'is_atomic_open()' helper and the way that nfs_atomic_lookup() will substitute an OPEN call for the usual LOOKUP if it sees that the caller is trying to open a file that might potentially be a regular file. > 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? Lookup permission checks would be replaced with open permission checks on the server. IOW: the operation could potentially fail due to a completely unrelated issue. Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
