On Wed, Jun 22, 2011 at 07:00:20PM -0400, Trond Myklebust wrote:
> > 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?
It always worked that way, all the way back to Unix v6 (and I'm fairly sure
to earlier than that; don't have v5 kernel source, unfortunately). Worked
that way in Linux since 0.02/0.03/0.10, when Linus first added mknod(2)
(presumably 0.01 had been tested with /dev populated by Minix ;-)
As for POSIX, what it says is
The only portable use of mknod() is to create a FIFO-special file.
If mode is not S_IFIFO or dev is not 0, the behaviour of mknod() is
unspecified.
and we support it for all non-directories. Always had...
Note that the right thing to do is to issue CLOSE and _not_ call
lookup_instantiate_filp() if we are called from sys_mknodat(). We don't
want to leak stateid...
--
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
