Re: [heads-up] mknod() broken on nfs4

[Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html