>
> So long as the route is marked RTF_UP, it cannot be deleted. In a
> single-threaded kernel, it is not possible for this code to be
> preempted, so there is no means by which the route flags could be
> changed. (RTF_UP is unset when and only when the route is deleted
> from the radix tree.)
I
if (rt->rt_flags & RTF_GATEWAY) /* XXX
How can we be sure that rt won't be freeed by
any other kernel thread now ??
XXX */
> Why is rt_refnt decreased so early and not later ?
In the non-SMP kernel, the kernel can't be preempted so anothe
< said:
> Why is rt_refnt decreased so early and not later ?
So long as the route is marked RTF_UP, it cannot be deleted. In a
single-threaded kernel, it is not possible for this code to be
preempted, so there is no means by which the route flags could be
changed. (RTF_UP is unset when and only
>
> The roadmap for locking up the IP stack looks like roughly like ifaddr
> ref counts, ifnet list, routing radix tree, ARP, ifaddr uses, and rtentry.
However, it seems that the rtentries' rt_refcnt are not used like ifaddr,
ifnet, ... It looks like something dirty has been done a long time ago
rtentry will get its own lock.
The roadmap for locking up the IP stack looks like roughly like ifaddr
ref counts, ifnet list, routing radix tree, ARP, ifaddr uses, and rtentry.
I'm a little over 3/5 of the way done along this path.
Jeffrey
/*
* Lookup or enter a new address in arptab.
*/
static struct llinfo_arp *
arplookup(addr, create, proxy)
u_long addr;
int create, proxy;
{
register struct rtentry *rt;
static struct sockaddr_inarp sin = {sizeof(sin), AF_INET };
const char *why = 0;
