On Thu, Mar 10, 2016 at 12:16:29AM +0300, Cyrill Gorcunov wrote:
>
> Thanks for explanation, Dave! I'll continue on this task tomorrow
> tryin to implement optimization you proposed.
OK, here are the results for the preliminary patch with conntrack running
---
[root@s125 ~]# ./exploit.sh
START 4 addresses STOP 1457604516 1457604518
START 2704 addresses STOP 1457604520 1457604521
START 10404 addresses STOP 1457604533 1457604534
START 23104 addresses STOP 1457604566 1457604567
START 40804 addresses STOP 1457604642 1457604643
START 63504 addresses STOP 1457604809 1457604810
It takes ~1 second for each case, which is great.
---
net/ipv4/devinet.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
Index: linux-ml.git/net/ipv4/devinet.c
===================================================================
--- linux-ml.git.orig/net/ipv4/devinet.c
+++ linux-ml.git/net/ipv4/devinet.c
@@ -403,7 +403,18 @@ no_promotions:
So that, this order is correct.
*/
rtmsg_ifa(RTM_DELADDR, ifa1, nlh, portid);
- blocking_notifier_call_chain(&inetaddr_chain, NETDEV_DOWN, ifa1);
+
+ if (!in_dev->dead || (in_dev->dead && !ifa1->ifa_next)) {
+ /*
+ * We might be destroying device with millions
+ * of addresses assigned, so we need to call
+ * the notifier on the last pass only, otherwise
+ * conntack code (if kernel supports) gonna scan
+ * on each cleanup iteration wasting huge amount
+ * of time.
+ */
+ blocking_notifier_call_chain(&inetaddr_chain, NETDEV_DOWN,
ifa1);
+ }
if (promote) {
struct in_ifaddr *next_sec = promote->ifa_next;
