netdev - Re: [PATCH] inet: delay address promotion check until last request in message

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20151108215641.GA16147@neilslaptop.think-freely.org>
Date:	Sun, 8 Nov 2015 16:56:41 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	Julian Anastasov <ja@....bg>
Cc:	netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	James Morris <jmorris@...ei.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
	Patrick McHardy <kaber@...sh.net>
Subject: Re: [PATCH] inet: delay address promotion check until last request
 in message

On Sat, Nov 07, 2015 at 01:49:25AM +0200, Julian Anastasov wrote:
> 
> 	Hello,
> 
> On Fri, 6 Nov 2015, Neil Horman wrote:
> 
> > The solution is to recognize that its pointless to promote an address to be a
> > new primary, if there is a possibility that it will just be removed in the near
> > future.  As such this patch peeks ahead to the next request in the provided
> > netlink message, and, if it is both valid and a RTM_DELADDR request, skips the
> > promotion check.  This eliminates the need to iterate through a nested for loop
> 
> 	flush can provide many parameters. As there is no
> any kind of indication in the netlink message that all addresses
> are removed, we can not avoid the promotion.
> 
This is true, but seems irrellevant to me.  A flush operation is a sequence of
RTM_DELADDR operations in a one or more netlink packets.  The way my patch is
written, if a set of DELADDR requests is interspersed with other non DELADDR
requests, then we do a promotion check between each consecutive set of DELADDR
requests.  As such, all that happens is that the promotion check happens
possibly more often than needed.  Its not optimal, but not harmful either.


> > +	 * Only check for address promotion when this is the last request
> > +	 * in this netlink transaction.  It allows this operation to complete
> > +	 * in O(n) time rather than O(n^2)
> 
> 	It is not correct to assume that one promotion per
> transaction is enough. The promotion happens in every subnet,
> it was not once per device.
> 

I'm not sure I understand the relevance here.  All I'm doing is, in effect
masking the promote_secondaries sysctl for an interface doing a flush operation.
Its equivalent to doing this in user space:

echo 0 > /proc/sys/net/ipv4/conf/<ifc>/promote_secondaries
A=`some arbitrary address in <ifc>`
ip addr del <every addressin in <ifc> except A>
echo 1 > /proc/sys/net/ipv4/conf/<ifc>/promote_secondaries
ip addr del A

Can you please explain to me the use case in which delaying a promotion
operation until we think we're done ('done' being defined by the above transition
from a DELADDR operation to a non-DELADDR operation in a netlink packet)
produces an outcome that differs from the expectation with this patch in place?

Best
Neil

> Regards
> 
> --
> Julian Anastasov <ja@....bg>
> 
--
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