Page MenuHomeFreeBSD

Simplify ifa/ifp refcounting in the routing stack.
ClosedPublic

Authored by melifaro on Sun, Feb 21, 2:29 PM.

Details

Summary

The routing stack control depends on quite a tree of functions to determine the proper attributes of a route such as a source address (ifa) or transmit ifp of a route.

When actually inserting a route, stack needs to ensure that ifa and ifp points to the entities that are still valid.
Validity means slightly more than just pointer validity - stack need guarantee that the provided objects are not scheduled for deletion.

Currently, callers either ignore it (most ifp parts, historically) or try to use refcounting (ifa parts). Even in case of ifa refcounting it's not always implemented correctly. For example, some codepaths inside rt_getifa_fib() are referencing ifa while not holding any locks, resulting in the referencing scheduled-for-deletion ifa.

Instead of trying to fix all of the callers by enforcing proper refcounting, switch to a different model.
As the rib_action() already requires epoch, do not require any stability guarantees other than the epoch-provided one.
Use newly-added conditional versions of the refcounting functions (ifa_try_ref(), if_try_ref()) and fail if any of these fails.

This addresses quite a number of corner cases in the route modification handling AND makes it simpler.

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

melifaro added a reviewer: network.

I like, that the ugly "reference" paramenter is gone. It was never used.

sys/net/route/nhop_ctl.c
541–556

Can you merge that into a single

if (ng->...sent == NULL || !ref...deps(ng)) {
   if (ng->...send)
      counter..free();

to avoid code duplication?

Or something like

if (!ng->...sent) {
   error = ENOMEN;
   goto fail;
}
sys/net/route/nhop_ctl.c
541–556

Yeah. Tried that, but it doesn't look any better, at least in my view.

There are only 2 lines that is actually the same in these blocks. Merging two blocks into one adds too many conditions (how do we easily distinguish between ENOMEM and EAGAIN?).

I'd rather leave them as is - at least it's easy to read.

This revision was not accepted when it landed; it landed in state Needs Review.Mon, Feb 22, 11:38 PM
This revision was automatically updated to reflect the committed changes.