Re: vn_open, EDUPFD, EMOVEFD

[christos%astron.com@localhost (Christos Zoulas)]

In article <YNnt+PJaqq22pHcm%netbsd.org@localhost>,
David Holland  <dholland-tech%netbsd.org@localhost> wrote:
>
>* Does anyone know why dev/kloader.c calls namei and then vn_open on
>the same path? I remember seeing this before and leaving it alone
>because nobody I could find was sure what the deal was, but it's
>unlikely to work as-is and increasingly likely to break over time...

Just fix it, and if something breaks we'll put it back.

>diff -r 4c2d0a182ef8 external/cddl/osnet/sys/sys/vnode.h
>--- a/external/cddl/osnet/sys/sys/vnode.h	Sun Jun 27 18:13:54 2021 -0400
>+++ b/external/cddl/osnet/sys/sys/vnode.h	Mon Jun 28 11:05:45 2021 -0400
>@@ -239,7 +239,6 @@
>     vnode_t **vpp, enum create crwhy, mode_t umask)
> {
> 	struct pathbuf *pb;
>-	struct nameidata nd;
> 	int error;
> 
> 	ASSERT(seg == UIO_SYSSPACE);
>@@ -248,11 +247,9 @@
> 	ASSERT(umask == 0);
> 
> 	pb = pathbuf_create(pnamep);
>-	NDINIT(&nd, LOOKUP, NOFOLLOW, pb);
>-	error = vn_open(&nd, filemode, createmode);
>+	error = vn_open(NULL, pb, 0, filemode, createmode, vpp, NULL, NULL);

This is the only NOFOLLOW NDINIT case, should that be 'createmode | O_NOFOLLOW'?


>-	NDINIT(&nd, CREATE, LOCKPARENT, pb);
> 	
> 	/*
> 	 * Since we do not hold ulfs_extattr_uepm_lock anymore,
> 	 * another thread may race with us for backend creation,
>-	 * but only one can succeed here thanks to O_EXCL
>+	 * but only one can succeed here thanks to O_EXCL.
>+	 *
>+ 	 * backing_vp is the backing store. 
> 	 */
>-	error = vn_open(&nd, O_CREAT|O_EXCL|O_RDWR, 0600);
>+	error = vn_open(NULL, pb, 0, O_CREAT|O_EXCL|O_RDWR, 0600,
>+			&backing_vp, NULL, NULL);

I guess O_CREAT will do the LOCKPARENT later...
I would have preferred if EMOVEFD/EDUPFD were gc'ed as part of the patch,
because there is a lot of ugliness left.

christos