5.2-rel, route.c question
David W. Hankins
David_Hankins at isc.org
Thu Jan 29 15:22:02 PST 2004
While looking at rtalloc1 in depth, trying to figure out the recursive
lock Peter mailed here a little while ago, I noticed something unrelated
about rtalloc1 I was hoping someone could explain to me.
At route.c:161 (cvs vers 184.108.40.206), I notice that it locks the rt pointer
it plans on returning, but does not inc the reference count.
The other two execution paths of rtalloc1 both lock & inc the ref
And later, in rtrequest1 (route.c:784), a call to rtalloc1 is made, and
in one case RTFREE_LOCKED(rt) is used, in the other rtexpunge is used
which looks safe to me either way.
IFF rtalloc1 did not RT_ADDREF(), AND rtrequest1 RTFREE_LOCKED()'s it,
then will the rt not be freed out from under the other reference? And
badness can then ensue?
I'm hoping someone more familiar with the code can tell me I'm wrong.
I've never read a line of it until today, so it's probable I'm just
David W. Hankins "If you don't do it right the first time,
you'll just have to do it again."
-- Jack T. Hankins
More information about the freebsd-current