On Sun, 30 Mar 2003, Greg Troxel wrote:

>   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 :-)

Ugh. While I want to say it's ok to modify it, something else will come
along some day & expect it to not be modified. We should either not modify
it or document what modifications are ok. Since I really have no idea what
modifications are ok and don't have the time to see what is in our kernel
right now, I'd rather we just not modify the flag.

>   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)?

Could you send me a new version of the patch, that saves off the flag
values? Also, I'd say save the old flags, set the whole flag word to what
you want, then restore the old contents. For instance, do we want
SAVEPARENT, etc.

I can commit it to -current, but I don't have 1.6 to test against, so I'm
hesitant about a pullup.

Take care,

Bill