On Wed, 2011-06-22 at 01:23 +0100, Al Viro wrote: > 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. I agree that we should error out gracefully instead of blowing up, but I fail to see why we want to support mknod for a regular file: it's not a posix interface, nor is it substantially different from open(O_CREAT| O_EXCL|O_NOFOLLOW). What is it's purpose? > BTW, AFAICS fuse will oops in such situation as well... -- 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
