On 10/14/15 7:06 PM, David Miller wrote:
From: David Ahern <d...@cumulusnetworks.com>
Date: Wed, 14 Oct 2015 10:09:59 -0600
This latest patch makes IPv6 static addresses on par with IPv4,
including error paths.
I don't agree with ipv4's behavior... and just because ipv4 does
something poorly doesn't mean we get a free pass to replicate that
lazyness in ipv6.
As I stated this patch makes IPv6 on par with IPv4 with regards to
saving the address and lack of error handling back to the user should a
failure happen on a link up. Yes, it is best to give the user
notification of a failure, but step back for a moment and look at the
bigger picture:
At best the address is saved and restored on a link up (the expected
outcome for 99.999999...% of the time). At worst the address is removed
because the prefix route fails a memory allocation and the user is not
notified. But that is exactly what happens today - the address is
dropped and the user has to restore it.
As for the 1 failure path -- it's a GFP_ATOMIC memory allocation
failure. Frankly if that happens lack of an address on an interface is
the least of the user's problems.
As for the options to fix this existing shortcoming:
1. The existing call_netdevice_notifiers infra does not allow a notifier
to 'fail' the transaction and roll it back or even to give the user an
error message.
2. Stashing the prefix route has its merits but it has to deal with
error paths as well. What if the address is deleted? What if the mask is
changed while the device is a down state? What if the device is deleted?
Sure, handle those cases but what other paths are missing from that list?
Both paths introduce a lot of complexity all b/c we want to save the
address on a link and restore the route on a link up.
Why not take this as a start point that at least does the right thing
almost every time?
David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
