Subject: Re: [solution] vnode refcount panic, perhaps due to kern/vfs_lookup.c:lookup()
To: Bill Studenmund <email@example.com>
From: Greg Troxel <firstname.lastname@example.org>
Date: 03/30/2003 20:14:42
The vnode op should behave as described in vnode_if.src. For symlink, it
is defined to return with the parent unlocked, not with the parent's state
as set by the absense of LOCKPARENT. VOP_LOOKUP is the only call AFAIK
that is defined to respect LOCKPARENT.
Good point; I should have realized that.
For sys_symlink, the componentname parameter is defined as IN, and
thus it seems it should not be modified. So, while the patch I sent
seems OK, it would seem that consing up a fresh struct componentname
for the VOP_LOOKUP is better. Either that or restoring the LOCKPARENT
flag after the call. But I don't see it written anywhere that the
componentname struct is not modified :-)
I think that the coda_symlink change needs to happen, and that sys_symlink
is not wrong.
You have convinced me. Should I be filing a PR, or are you or Jaromir
going to commit it (presumably to -current first, with a pullup
request to follow)?