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
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.
On Wed, 8 Jan 2003 23:22:22 +0100, Vincent Jardin [EMAIL PROTECTED] 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
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 another
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
