[Top] [All Lists]

Fix ipv6_ifa_notify race (was: IPv6 "badness" in recent releases)

To: "David S. Miller" <davem@xxxxxxxxxxxxx>
Subject: Fix ipv6_ifa_notify race (was: IPv6 "badness" in recent releases)
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 19 Nov 2004 20:49:24 +1100
Cc: yoshfuji@xxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, acme@xxxxxxxxxxxxxxxx, Jeff Garzik <jgarzik@xxxxxxxxx>
In-reply-to: <E1CTR5h-0006ac-00@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <4197AC20.6020707@xxxxxxxxx> <E1CTR5h-0006ac-00@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040722i
On Mon, Nov 15, 2004 at 07:35:17AM +1100, Herbert Xu wrote:
> Could you please apply this patch and see if the warning triggers
> before the underflows start coming in? We already know that if it
> does then it can cause underflows but I want to make sure that
> this is what's causing your problems.

Well I think it's time to fix this bug so that we don't release
2.6.10 with it.

This is only a temporary hack that should be rolled back once
the locking in addrconf.c is fixed properly.  At the moment
the locking is just too twisted to fix properly for 2.6.10 :(

This patch doesn't even fix all the races in ipv6_ifa_notify.
For example, the anycast/multicast addresses may be left
standing should the race strike.  However, they should have
a much milder effect compared to a dead route in the routing
table :)

Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>

May I ask this question again: Is it possible to move some of
this complexity to user-space?

addrconf.c is by far the biggest file in net/ipv6.  This is
also not the first time we've had a serious bug in this file.
I recall fixing another timer-related bug in this file a year
ago that left dangling references on devices.

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page:
PGP Key:

Attachment: p
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>