Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Jun 2013 10:53:43 -0400
From:      Dheeraj Kandula <dkandula@gmail.com>
To:        freebsd-net@freebsd.org
Subject:   Route deletion when processing a packet by ip_output
Message-ID:  <CA%2BqNgxQMAHbV5JeBjoPzTuDGHj8n5%2B_u1BSJ3ist0wte8FmccA@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
Hey All,
              I have been going through the routing and packet processing
code in FreeBSD and am not sure how this scenario is handled though this
looks basic. Am I missing something here?

When ip_output function is processing a packet and uses a route to send it
on it's way to the destination, ip_output doesn't hold the read lock of the
routing tree while processing the packet. This can be observed from the
fact that the ignore flag is set to 0 when invoking in_rtalloc_ign().

Hence even though we increment the reference count for the route when we
perform a lookup, the route deletion code can proceed with the deletion as
the read lock is not acquired by anyone. i.e. there are no readers.

Hence acquiring the write lock succeeds for deletion. The rn_delete
disconnects the two nodes from the routing tree i.e. leaf and internal
nodes for the route. But in rtrequest1_fib(), the memory for route i,e.,
rtentry is not unallocated as the reference count is not 1. it will be 2.
But when we return from rtrequest1_fib() we don't have a handle on the
route entry.

Hence how do we get back to this route. I guess because we have a handle to
it via the route lookup  we can delete it once we call RT_REMREF macro. But
once the route is disconnected from the routing tree, it doesn't make sense
to use it. Isn't it? i.e. ip_output() may still use it to process the
packet.

Can anyone clarify this? Am I missing something here or didn't consider
something along the way.

Dheeraj



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BqNgxQMAHbV5JeBjoPzTuDGHj8n5%2B_u1BSJ3ist0wte8FmccA>