Re: [PATCH] ipv6: fix incorrect unregistration of sysctl when lastip deleted

[David Miller]

From: John Myers <jgmyers@xxxxxxxxxxxxxx>
Date: Wed, 27 Apr 2011 16:12:38 -0700

> When the last ip address is deleted, the kernel disables IPv6 on the
> interface. (Not sure why, but that's beside the point.) The call that
> does this is over-aggressive--it indicates the interface is about to
> be removed even though that isn't necessarily so.
> 
> This causes IPv6 to, among other things, unregister its sysctl
> parameters for the interface. Thus, the "accept_ra" and "addrconf"
> settings can't be set on the interface until after the interface has
> been brought back up, which is too late.
> 
> Signed-off-by: John Gardiner Myers <jgmyers@xxxxxxxxxxxxxx>
> Cc: stable@xxxxxxxxxx

I'm not applying this, at least without some more discussion.

I can't see what you gain from this change.

First of all, when the machine boots up, you already have the problem
that you cannot set the accept_ra and addrconf sysctl settings before
the first ipv6 address is added to the interface.

So by definition you already cannot make the settings before it is
"too late" and the device is already engaging in ipv6 activity.

Giving you the capability to handle this across full ipv6 address
deletions on the device later on doesn't add anything, and at best it
gives people a false sense of security about being able to preserve
these settings across an ipv6 disable on the device.

If people are going to use this new behavior to do some trick like:

1) Let device come up and assign ipv6 addresses so that sysctls appear
2) Set ipv6 sysctls how actually desired
3) Delete all ipv6 addresses
4) Add them all back

Then I doubly do not want to set a precedent for this kind of usage
by applying this patch.  Fix the real problem.

This behavior has been here, and intentionally so, since Alexey added
the "how" parameter to addrconf_ifdown() back in 1997.

Furthermore, there are other side effects to changing the 'how' parameter
to zero in this case and I haven't seen any analysis that those won't
cause any other undesirable side effects either.

So again, I'm not applying this patch, sorry.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/