In article <ynnt+pjaqq22p...@netbsd.org>,
David Holland <dholland-t...@netbsd.org> 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
