Subject: Re: Incorrect vattr passed to VOP_SYMLINK?
To: YAMAMOTO Takashi <>
From: Julio M. Merino Vidal <>
List: tech-kern
Date: 08/15/2005 10:20:05
On 8/15/05, YAMAMOTO Takashi <> wrote:
> > while writing tmpfs' symlink vnode operation, I discovered that the
> > vattr argument it receives does not have a correct type set in it.
> > Other operations, such as the creation of files, directories, pipes
> > and devices have the corresponding type in vap->va_type.
> >
> > I think the symlink operation should be consistent with all others
> > because this seems an unintended ommission.
> >
> > Does anybody mind if I commit the patch shown below?  (This will
> > let me kill a workaround for this issue in tmpfs ;)
> i don't think that va_type is used by anyone in this case.
> it's normal for VOPs to use only parts of given vattr.

The thing is that I have a common function used by all VOPs that
create new nodes.  This function bases its decision on the kind of
object that has to be created on the value of va_type, and was
working fine until I added symlinks, because the attribute had
the VNON value.

Furthermore, I have several assertions in those VOPs to verify that
va_type's value is correct WRT the call (e.g., VOP_SYMLINK needs
va_type =3D=3D VLNK).  As I've seen, NFS code also does this, but
only in the nfs_create function (see nfs_vnops.c:1726).

I'm not saying that the caller of VOP_SYMLINK is incorrect, because
it's clear that no other code relies on this little detail I've mentioned.
However, it'd be modified to be consistent with other calls so that
my specific code could work ;)  Otherwise (and as you suggest
below), we'd need to make it clear that va_type is not meant to be
used in these cases.

> i think it's better to have some explicit bitmasks in vattr
> to designate which members are valid, and
> document which members are required by each VOPs.

That'd be nice.

> btw, don't forget nfsd if you go ahead.

What happens with nfsd?  I've checked its code, as well as the
one in sys/nfs and cannot find how it could affect it...  (haven't
looked in deep detail, though).


Julio M. Merino Vidal <>
The NetBSD Project -