On Sat, Dec 26, 2015 at 7:38 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Sat, Dec 26, 2015 at 07:11:16PM -0500, Trond Myklebust wrote: > >> Ah... IOW: That so called "fast path" crap in do_last() is screwing us >> over by forcing us to to 2 ACCESS calls. The first being done for no >> good reason by the VFS, and the second being done in the OPEN call to >> the server in the NFS client. > > Excuse me, but this is complete BS. First of all, are you suggesting > that every filesystem out there must push the permission checks into > its ->open()? This may_open() is where they normally happen... > > Moreover, the things like "this mount is r/o, don't let anything to > be opened on it" are inherently client-side. It's a property of > vfsmount; the same fs instance might be accessible r/w in another > place. And things like opening a device node, etc. are not reaching > the server at all. The may_open() is now happening before NFS gets a chance to issue the OPEN rpc call, which is a change w.r.t. the lookup intent code. The ordering is significant because it means the OPEN can no longer prime the access cache. >> > Merry Christmas >> >> Suggestions Al? > > Make nfs_permission() relax the checks when it sees MAY_OPEN, if you know > that things will be caught by server anyway? That can work as long as we're guaranteed that everything that calls inode_permission() with MAY_OPEN on a regular file will also follow up with a vfs_open() or dentry_open() on success. Is this always the case? -- 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
