rtalloc()/rtfree() problems on CURRENT

[Gleb Smirnoff]

On Tue, Feb 24, 2004 at 04:04:08PM +0300, Gleb Smirnoff wrote:
T> A> Ah, sorry, forgot that in my last email.  The only thing is to use RTFREE().
T> A> At first I thought your reassigning of rt is a problem, but you free the
T> A> correct ro.ro_rt later.
T> 
T> Thank you! I'll try everything you suggested today night.

Thanks again. Using RTFREE() fixed the problem. It works OK both
on STABLE and CURRENT.

If you don't mind I have one more question, though. Looking through kernel
code, seeking for examples, I have found following in in_gif.c:

                rt = rtalloc1((struct sockaddr *)&sin, 0, 0UL);
                if (!rt || rt->rt_ifp != ifp) {
#if 0
                        log(LOG_WARNING, "%s: packet from 0x%x dropped "
                            "due to ingress filter\n", if_name(&sc->gif_if),
                            (u_int32_t)ntohl(sin.sin_addr.s_addr));
#endif
                        if (rt)
                                rtfree(rt);
                        return 0;
                }
                rtfree(rt);

And it doesn't crash. Looking through the code I understood that
in case of rtalloc()/rtfree() or rtalloc_ign()/rtfree() macro RT_UNLOCK
is called twice, and this leads to panic. But in case of rtalloc1()/rtfree()
everything is OK, since RT_UNLOCK is called once.

So, the question is: if I need some readonly access to routing table can
I use rtalloc1()/rtfree() or not? Will RTFREE be mandatory in future?
This will save some small amount of CPU time, but this code is executed
really often.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE