Subject: VNODEOPs & SAVESTART in cn_flags
To: None <>
From: Chris Jepeway <>
List: tech-kern
Date: 01/29/2002 01:15:58
Some vnode operations in some file systems
will pay attention to whether the SAVESTART
bit is set in the cn_flags member of their
componentname structure.  Others ignore it
and always call PNBUF_PUT().  A table of a few:

    Honors SAVESTART        Always PNBUF_PUT()s
    ----------------        -------------------
        coda_link                ufs_link
      msdosfs_mkdir            ext2fs_mkdir
        ufs_mknod               nfs_mknod

The following patch to v 1.82 of ufs/ufs/ufs_vnops.c
illustrates the issue for ufs_link() (the patch is built
from a private repository, so ignore its version numbers):

Index: ufs/ufs/ufs_vnops.c
RCS file: /cvsroot/src/sys/ufs/ufs/ufs_vnops.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ufs/ufs/ufs_vnops.c	2001/10/25 21:49:09	1.1
+++ ufs/ufs/ufs_vnops.c	2002/01/27 18:49:29	1.2
@@ -679,7 +679,8 @@
 		if (DOINGSOFTDEP(vp))
-	PNBUF_PUT(cnp->cn_pnbuf);
+	if ((cnp->cn_flags & SAVESTART) == 0)
+		PNBUF_PUT(cnp->cn_pnbuf);
 	if (dvp != vp)
 		VOP_UNLOCK(vp, 0);

One might argue this sorta thing doesn't matter much:
after all, VOP_LINK() is only called in places that don't
set SAVESTART.  However, differences like these across
the various file systems make introducing new file systems
a bit harder.  Two examples:

    o  a stacked f/s might want to use the pathname
       after a direct VOP_() call to its lower f/s

    o  expanding the VOP_() interface to support a f/s
       that detects soft failures withe a return code
       that means "please retry the VOP_(), it might
       succeed now" isn't as fun if you can't use the
       FFS as a baseline

Regardless, it seems like every f/s should handle a
given VOP_() the same way.  Question is, well, what's
that same way?  I'd argue that at least all VOP_LINK()s
should honor SAVESTART, since most of the VOP_CREATE()s
seem to.

Thoughts?  Would a PR about inconsistencies wrt to
SAVESTART be in order?

Chris <>.