From: Herbert Xu <[EMAIL PROTECTED]>
Date: Mon, 1 Aug 2005 14:30:46 +1000
> Well the problem is that the kernel simply doesn't have the information
> to selectively flush dst's given a new SA. All it can do is flush out
> all cached dst entries when a new SA is added. Because SA changes are
> actually pretty common (as opposed to policy changes which shouldn't
> occur in a stable system) this is something I'd like to avoid if
> possible.
I see.
We can avoid the flushing damage to DSTs of the effected policy.
At least I think we can do that cleanly. Do you think that is
a middle ground that might be acceptable to you?
The idea is this:
1) Add to xfrm_policy
struct list_head sa_dst_list;
2) Add to xfrm_dst
struct xfrm_policy *policy;
struct list_head policy_list;
struct dst_entry already has an "xfrm" pointer that allows
us to get back to the state, but that unfortunately doesn't
allow one to get back to the policy.
My mind is fuzzy on this, is there a many to one relationship
from SAs to policies? If so, my idea is dead in the water.
If not, read on :-)
The idea is that when we build a bundle, the top xfrm_dst gets
linked into the sa_dst_list of the policy we matched.
When an SA changes, we walk that assosciated policies DST list
marking them ->obsolete
When a policy is destroyed, we walk the list marking the DSTs
obsolete and unlinking them from the policy list.
When top-level xfrm_dst objects are freed up, we unlink them
from the policy list.
The xfrm_policy->lock protects the policy list.
One nice aspect of this is that it keeps us from having to
(for example) consider schemes such as incrementing the flow
cache generation ID and checking that in the socket dst cache
verify code.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
