From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: [heads-up] mknod() broken on nfs4
Date: Wed, 22 Jun 2011 00:59:00 +0100
Message-ID: <20110621235900.GB11521@ZenIV.linux.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel@vger.kernel.org
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:41006 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1757407Ab1FUX7D (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 21 Jun 2011 19:59:03 -0400
Content-Disposition: inline
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

	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...