ipv6: Reparent temporary address(es) if global address was, deleted from userspace
Subsystems (3)
PATCH v2 1/1 ipv6: Reparent temporary address(es) if global address was, deleted from userspace
If the kernel takes care of global and temporary addresses it can happen that the global address is deleted from userspace,
e.g. by network managers in case the link goes (temporarily) down. In addition to the then orphaned temporary address(es) the next RA will create a new temporary address. Therefore we might end up with more than one non-deprecated temporary address for the same prefix for a longer period of time (>regen_advance). According to RfC4941 sect. 3.4 this should not happen.
Fix this by reparenting orphaned temporary addresses.
v2: style fixes
--- net/ipv6/addrconf.c | 30 +++++++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-)
net/ipv6/addrconf.c +27 -3
@@ -2077,14 +2077,33 @@ static void manage_tempaddrs(struct inet6_dev *idev, {u32 flags;struct inet6_ifaddr *ift; +unsigned long regen_advance;read_lock_bh (&idev->lock); + regen_advance = idev->cnf.regen_max_retry * + idev->cnf.dad_transmits * +NEIGH_VAR (idev->nd_parms,RETRANS_TIME ) /HZ ;/* update all temporary addresses in the list */ list_for_each_entry (ift, &idev->tempaddr_list, tmp_list) {int age, max_valid, max_prefered; +bool reparent = false; -if (ifp != ift->ifpub) -continue ; +spin_lock (&ift->lock); +if (ifp != ift->ifpub) { +/* reparent if orphaned temporary address with same +* prefix is found +*/ +if (ipv6_prefix_equal (&ift->addr, &ifp->addr, + ift->prefix_len)) { +in6_ifa_hold (ifp); +in6_ifa_put (ift->ifpub); + ift->ifpub = ifp; + reparent = true; + }else { +spin_unlock (&ift->lock); +continue ; + } + }/* RFC 4941 section 3.3: * If a received option will extend the lifetime of a public
@@ -2110,7 +2129,6 @@ static void manage_tempaddrs(struct inet6_dev *idev,if (prefered_lft > max_prefered) prefered_lft = max_prefered; -spin_lock (&ift->lock); flags = ift->flags; ift->valid_lft = valid_lft; ift->prefered_lft = prefered_lft;
@@ -2119,6 +2137,12 @@ static void manage_tempaddrs(struct inet6_dev *idev, ift->flags &= ~IFA_F_DEPRECATED ;spin_unlock (&ift->lock); +/* Don't create a temporary address if we reparented one which +* is preferred more than regen_advance +*/ +if (reparent && prefered_lft > regen_advance) + create = false; +if (!(flags&IFA_F_TENTATIVE ))ipv6_ifa_notify (0 , ift); }
Signature · 1 line
1.9.1.315.g3f09db0.dirty
Quoted 9 lines · Heiner Kallweit
If the kernel takes care of global and temporary addresses it can happen that the global address is deleted from userspace,
e.g. by network managers in case the link goes (temporarily) down. In addition to the then orphaned temporary address(es) the next RA will create a new temporary address. Therefore we might end up with more than one non-deprecated temporary address for the same prefix for a longer period of time (>regen_advance). According to RfC4941 sect. 3.4 this should not happen.
Quoted 5 lines
Fix this by reparenting orphaned temporary addresses.
v2: style fixes
Signed-off-by Heiner Kallweit <[email protected]>
Looks good!
Btw. do you intend this as a bugfix for net or net-next? net-next is currently closed and you would have to resubmit this patch as soon as net-next opens back up. A notification will be send to this list.
Current kernels only print a warning if this happens, so IMHO net-next would be ok?
Thanks,
Hannes
Am 07.04.2014 12:22, schrieb Hannes Frederic Sowa:
Quoted 21 lines · Heiner Kallweit
Quoted 9 lines
If the kernel takes care of global and temporary addresses it can happen that the global address is deleted from userspace,
e.g. by network managers in case the link goes (temporarily) down. In addition to the then orphaned temporary address(es) the next RA will create a new temporary address. Therefore we might end up with more than one non-deprecated temporary address for the same prefix for a longer period of time (>regen_advance). According to RfC4941 sect. 3.4 this should not happen.Quoted 5 lines
Fix this by reparenting orphaned temporary addresses.
v2: style fixes
Signed-off-by Heiner Kallweit <[email protected]>Looks good!
Btw. do you intend this as a bugfix for net or net-next? net-next is currently closed and you would have to resubmit this patch as soon as net-next opens back up. A notification will be send to this list.
Quoted 8 lines
Current kernels only print a warning if this happens, so IMHO net-next would be ok?
Thanks,
Hannes
Even though the kernel doesn't fully follow RfC 4941 in this scenario I didn't notice any real harm. Therefore I would agree and consider it more an improvement than a bugfix. I'll resubmit once net-next is open again.
Regards, Heiner