From patchwork Tue Mar 29 17:21:11 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kamal Mostafa X-Patchwork-Id: 603080 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) by ozlabs.org (Postfix) with ESMTP id 3qZHch6xqcz9sBf; Wed, 30 Mar 2016 04:21:24 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.76) (envelope-from ) id 1akxKT-0003xA-43; Tue, 29 Mar 2016 17:21:21 +0000 Received: from mail-pf0-f193.google.com ([209.85.192.193]) by huckleberry.canonical.com with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.76) (envelope-from ) id 1akxKO-0003wl-AW for kernel-team@lists.ubuntu.com; Tue, 29 Mar 2016 17:21:16 +0000 Received: by mail-pf0-f193.google.com with SMTP id u190so3456909pfb.2 for ; Tue, 29 Mar 2016 10:21:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=R5GMJFLvzebMDElji3QkX7PTmQFC+XMUKeuFEAwiLNs=; b=i3/O6rEyvWjP5OvWmeE2EsxQoxoyP6RVUAtV6d6/eJUBa0TaPNx6PbokaaQKX6ROo7 cdIeYlmS31yyapZFru0ghzg7dsl++aa8yH+RmY5H2PbcYYwiKUVjMXTYY5C1LNDcTySm x2hxyFuUJKjC0DH5nRXq8aaf6Bxuz8Wml70ZPZeBQuuy8o7CisduGiTuWwArV1VywUdp i9gFUe21jlLi8iFxyj+DHWk+yOasy2yZkgauIvDhuZwjlQJr6NJZixDptSwCSQSF6ijp /4DIHHCjVngYVcVX7o1/z5zSN6No52whouPxw2kfTqFuEB7XyvKbKRq2eKsr5S+U8eL9 tiUQ== X-Gm-Message-State: AD7BkJIzSUkrGl92MC+rIzEPRADzcLmO0ly6LMf7+UdyPBMZB3l4DTj8MXqkeAyIeM3JjA== X-Received: by 10.98.10.83 with SMTP id s80mr5291359pfi.120.1459272074862; Tue, 29 Mar 2016 10:21:14 -0700 (PDT) Received: from fourier (c-76-126-59-13.hsd1.ca.comcast.net. [76.126.59.13]) by smtp.gmail.com with ESMTPSA id r68sm44584869pfa.33.2016.03.29.10.21.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Mar 2016 10:21:14 -0700 (PDT) Received: from kamal by fourier with local (Exim 4.86_2) (envelope-from ) id 1akxKK-0008W2-C4; Tue, 29 Mar 2016 10:21:12 -0700 From: Kamal Mostafa To: "David S. Miller" Subject: [3.19.y-ckt stable] Patch "ipv4: Don't do expensive useless work during inetdev destroy." has been added to the 3.19.y-ckt tree Date: Tue, 29 Mar 2016 10:21:11 -0700 Message-Id: <1459272071-32698-1-git-send-email-kamal@canonical.com> X-Mailer: git-send-email 2.7.4 X-Extended-Stable: 3.19 Cc: Kamal Mostafa , kernel-team@lists.ubuntu.com, Solar Designer X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.14 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: kernel-team-bounces@lists.ubuntu.com This is a note to let you know that I have just added a patch titled ipv4: Don't do expensive useless work during inetdev destroy. to the linux-3.19.y-queue branch of the 3.19.y-ckt extended stable tree which can be found at: http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.19.y-queue This patch is scheduled to be released in version 3.18.8-ckt18. If you, or anyone else, feels it should not be added to this tree, please reply to this email. For more information about the 3.19.y-ckt tree, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable Thanks. -Kamal ---8<------------------------------------------------------------ From 1f6a4916bb907af259559c7d2585598f9f6d4129 Mon Sep 17 00:00:00 2001 From: "David S. Miller" Date: Sun, 13 Mar 2016 23:28:00 -0400 Subject: ipv4: Don't do expensive useless work during inetdev destroy. commit fbd40ea0180a2d328c5adc61414dc8bab9335ce2 upstream. When an inetdev is destroyed, every address assigned to the interface is removed. And in this scenerio we do two pointless things which can be very expensive if the number of assigned interfaces is large: 1) Address promotion. We are deleting all addresses, so there is no point in doing this. 2) A full nf conntrack table purge for every address. We only need to do this once, as is already caught by the existing masq_dev_notifier so masq_inet_event() can skip this. Reported-by: Solar Designer Signed-off-by: David S. Miller Tested-by: Cyrill Gorcunov Signed-off-by: Kamal Mostafa --- net/ipv4/devinet.c | 4 ++++ net/ipv4/fib_frontend.c | 4 ++++ net/ipv4/netfilter/nf_nat_masquerade_ipv4.c | 12 ++++++++++-- 3 files changed, 18 insertions(+), 2 deletions(-) -- 2.7.4 diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c index 4f8ea2d..22ae8f7 100644 --- a/net/ipv4/devinet.c +++ b/net/ipv4/devinet.c @@ -334,6 +334,9 @@ static void __inet_del_ifa(struct in_device *in_dev, struct in_ifaddr **ifap, ASSERT_RTNL(); + if (in_dev->dead) + goto no_promotions; + /* 1. Deleting primary ifaddr forces deletion all secondaries * unless alias promotion is set **/ @@ -380,6 +383,7 @@ static void __inet_del_ifa(struct in_device *in_dev, struct in_ifaddr **ifap, fib_del_ifaddr(ifa, ifa1); } +no_promotions: /* 2. Unlink it */ *ifap = ifa1->ifa_next; diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c index 23104a3..d4c698c 100644 --- a/net/ipv4/fib_frontend.c +++ b/net/ipv4/fib_frontend.c @@ -814,6 +814,9 @@ void fib_del_ifaddr(struct in_ifaddr *ifa, struct in_ifaddr *iprim) subnet = 1; } + if (in_dev->dead) + goto no_promotions; + /* Deletion is more complicated than add. * We should take care of not to delete too much :-) * @@ -889,6 +892,7 @@ void fib_del_ifaddr(struct in_ifaddr *ifa, struct in_ifaddr *iprim) } } +no_promotions: if (!(ok & BRD_OK)) fib_magic(RTM_DELROUTE, RTN_BROADCAST, ifa->ifa_broadcast, 32, prim); if (subnet && ifa->ifa_prefixlen < 31) { diff --git a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c index c6eb421..ea91058 100644 --- a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c +++ b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c @@ -108,10 +108,18 @@ static int masq_inet_event(struct notifier_block *this, unsigned long event, void *ptr) { - struct net_device *dev = ((struct in_ifaddr *)ptr)->ifa_dev->dev; + struct in_device *idev = ((struct in_ifaddr *)ptr)->ifa_dev; struct netdev_notifier_info info; - netdev_notifier_info_init(&info, dev); + /* The masq_dev_notifier will catch the case of the device going + * down. So if the inetdev is dead and being destroyed we have + * no work to do. Otherwise this is an individual address removal + * and we have to perform the flush. + */ + if (idev->dead) + return NOTIFY_DONE; + + netdev_notifier_info_init(&info, idev->dev); return masq_device_event(this, event, &info); }