netdev - Re: [PATCH net-next v5] net: ipv6: Make address flushing on ifdown optional

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 14 Oct 2015 20:46:35 -0600
From:	David Ahern <dsa@...ulusnetworks.com>
To:	David Miller <davem@...emloft.net>
Cc:	hannes@...essinduktion.org, netdev@...r.kernel.org,
	hannes@...hat.com, nicolas.dichtel@...nd.com
Subject: Re: [PATCH net-next v5] net: ipv6: Make address flushing on ifdown
 optional

On 10/14/15 7:06 PM, David Miller wrote:
> From: David Ahern <dsa@...ulusnetworks.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html