[Port-solaris] Re: vn_setpath

Frank Batschulat (private) frank.batschulat@drusus.de
Tue, 08 Jan 2013 23:07:29 +0100


On Tue, 08 Jan 2013 19:40:31 +0100, Andrew Deason <adeason@sinenomine.net> wrote:

>> +#if defined(AFS_SUN511_ENV)
>> +	    vn_renamepath(pvp, vp, aname2, strlen(aname2));
>> +#else
>
> We usually do this kind of thing by testing directly for the existence
> of the desired function. There is no problem with using this as soon as
> it appears, correct?

that is correct.

>> Btw, we've noticed something else you want to fix in afs_inactive():
>>
>> 1674     /*
>> 1675      * Solaris calls VOP_OPEN on exec, but doesn't call VOP_CLOSE when
>> 1676      * the executable exits.  So we clean up the open count here.
>> 1677      *
>> 1678      * Only do this for mvstat 0 vnodes: when using fakestat, we can't
>> 1679      * lose the open count for volume roots (mvstat 2), even though they
>> 1680      * will get VOP_INACTIVE'd when released by afs_PutFakeStat().
>> 1681      */
>>
>> We have fixed the overall VOP_CLOSE() is missing in the exec path
>> problem since Solaris 11 build 135.  This code above should be
>> disabled in Solaris 11 and later. VOP_CLOSE() is called on exec (on
>> the old executable), and exit and we also call VOP_OPEN on fork().
>> However it is not fixed in Solaris 10.
>
> That build number does not mean a lot to me; does that mean it's in
> every public Solaris 11 release?

yes it is, build 135 pre-dates Solaris 11 GA by quite a bit, its even in
the OpenSolaris code base before the "closure"

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/vnode.c#3022

so you are good to go for Openindiana/Illumos as well in case you care about them.

> I would be careful with disabling it,
> since that's not really something we can easily write a direct test for.

your call, we thought this may lead you astray and confuse the bean counting here
when we now call VOP_CLOSE() in Solaris 11 when you don't expect us todo so. you are in a much
better position to make that judgement actually.

> things? I would like to note where I got this information from when I
> say we should do X, Y, or Z in e.g. commit messages.

yeah, we can probably do that, wouldn't be the first time anyways.

cheers
frankB