[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100422091703.463665c0@nehalam>
Date: Thu, 22 Apr 2010 09:17:03 -0700
From: Stephen Hemminger <shemminger@...tta.com>
To: Jiri Bohac <jbohac@...e.cz>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
David Miller <davem@...emloft.net>, yoshfuji@...ux-ipv6.org,
netdev@...r.kernel.org
Subject: Re: IPv6: race condition in __ipv6_ifa_notify() and dst_free() ?
On Thu, 22 Apr 2010 17:49:08 +0200
Jiri Bohac <jbohac@...e.cz> wrote:
> On Thu, Apr 22, 2010 at 10:25:06PM +0800, Herbert Xu wrote:
> > This patch fixes this by using the DADFAILED bit to synchronise
> > the two paths while holding the ifp lock. It relies on the fact
> > that the TENTATIVE bit is always set during DAD, and that the
> > DADFAILED bit is only set on failure.
>
> But the addr_dad_failure()->...->ipv6_del_addr() path will
> still race with any other path calling ipv6_del_addr() (e.g. a
> manual address removal). Won't it?
>
> I still don't see why __ipv6_ifa_notify() needs to call
> dst_free(). Shouldn't that be dst_release() instead, to drop the
> reference obtained by dst_hold(&ifp->rt->u.dst)?
Yes, some more locking and race condition management is needed.
Something like the following (untested):
--- a/net/ipv6/addrconf.c 2010-04-22 09:11:54.594827858 -0700
+++ b/net/ipv6/addrconf.c 2010-04-22 09:15:59.224631752 -0700
@@ -720,13 +720,18 @@ static void ipv6_del_addr(struct inet6_i
hash = ipv6_addr_hash(&ifp->addr);
+ write_lock_bh(&idev->lock);
+ if (ifp->dead) {
+ write_unlock(&idev->lock); /* lost race with DAD */
+ return;
+ }
+
ifp->dead = 1;
- spin_lock_bh(&addrconf_hash_lock);
+ spin_lock(&addrconf_hash_lock);
hlist_del_init_rcu(&ifp->addr_lst);
- spin_unlock_bh(&addrconf_hash_lock);
+ spin_unlock(&addrconf_hash_lock);
- write_lock_bh(&idev->lock);
#ifdef CONFIG_IPV6_PRIVACY
if (ifp->flags&IFA_F_TEMPORARY) {
list_del(&ifp->tmp_list);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists