On Sat, Apr 22, 2017 at 09:40:37AM -0700, David Ahern wrote:
[...]
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 08f9e8ea7a81..97e86158bbcb 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -3303,14 +3303,24 @@ static void addrconf_gre_config(struct net_device
> *dev)
> static int fixup_permanent_addr(struct inet6_dev *idev,
> struct inet6_ifaddr *ifp)
> {
> - if (!ifp->rt) {
> - struct rt6_info *rt;
> + /* rt6i_ref == 0 means the host route was removed from the
> + * FIB, for example, if 'lo' device is taken down. In that
> + * case regenerate the host route.
> + */
> + if (!ifp->rt || !atomic_read(&ifp->rt->rt6i_ref)) {
> + struct rt6_info *rt, *prev;
>
> rt = addrconf_dst_alloc(idev, &ifp->addr, false);
The rt regernation makes sense.
> if (unlikely(IS_ERR(rt)))
> return PTR_ERR(rt);
>
> + spin_lock(&ifp->lock);
> + prev = ifp->rt;
> ifp->rt = rt;
I am still missing something on the new spin_lock:
1) Is there an existing race in the existing
ifp->rt modification ('ipf->rt = rt') which is
not related to this bug?
2) If there is a race in ifp->rt, is the above if-checks
on ifp->rt racy and need protection also? F.e. 'ifp->rt->rt6i_ref'
since ifp->rt could be NULL or ifp->rt->rt6i_ref
may not be zero later if there is concurrent
modification on ifp->rt?
> + spin_unlock(&ifp->lock);
> +
> + if (prev)
> + ip6_rt_put(prev);
Nit. ip6_rt_put() takes NULL.
> }
>
> if (!(ifp->flags & IFA_F_NOPREFIXROUTE)) {
> --
> 2.1.4
>
