On Wed, Jun 22, 2011 at 12:59:00AM +0100, Al Viro wrote: > Try mknod(path, 0777, 0); with path leading into nfs4. It > leads to call of nfs_open_create(), with nd->intent.open.file being > uninitialized. Note that LOOKUP_CREATE is set and so's LOOKUP_EXCL, > but LOOKUP_OPEN isn't. So nfs_atomic_lookup() falls through to > nfs_lookup(), which sees that we are doing exclusive create and just > does d_instantiate(dentry, NULL) and do nothing else. And then > we hit ->create()... > > Results are ugly - random errors (often -EINVAL or -ENOENT) > and possibility of memory corruption if we manage to generate a request > that won't fail on server. > > The really interesting question is what should we pass in > NFS_PROTO(dir)->create() in open_flags. I suspect that you are > checking the wrong flag there (LOOKUP_CREATE instead of LOOKUP_OPEN), > but I'm not sure what *should* be passed when LOOKUP_OPEN is not > there... Argh... Alas, it's not that simple. Even though the code in nfs_open_create() and nfs4_proc_create() seems to imply that passing NULL as ctx is OK and expected, in reality that blows up since we end up with NULL cred passed to nfs4_do_open(), which oopses on attempt to do get_rpccred(NULL) from nfs4_get_state_owner(). Folks, how is that code supposed to work? lookup_instantiate_filp() should *not* be called by vfs_create() triggered by mknod(). And I don't see any codepath in nfs_open_create() that would not step into that. ctx == NULL is the only thing that would skip it and it definitely isn't survivable by nfs4_proc_create(). Moreover, we need the rpc_cred to come from somewhere and nfs4_proc_create() needs to get it from us. BTW, AFAICS fuse will oops in such situation as well... -- 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
