From patchwork Tue Mar 29 17:25:44 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kamal Mostafa X-Patchwork-Id: 603093 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 3qZHjy0jhRz9sBf; Wed, 30 Mar 2016 04:25:58 +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 1akxOq-0004aV-Pg; Tue, 29 Mar 2016 17:25:52 +0000 Received: from mail-pf0-f196.google.com ([209.85.192.196]) by huckleberry.canonical.com with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.76) (envelope-from ) id 1akxOm-0004Yk-IV for kernel-team@lists.ubuntu.com; Tue, 29 Mar 2016 17:25:48 +0000 Received: by mail-pf0-f196.google.com with SMTP id n5so3461359pfn.1 for ; Tue, 29 Mar 2016 10:25:48 -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=kG1LXHJRhIsL6A7KQAw7yEx/bc9viRF2gPjC3NCJAlA=; b=HeV3wPc19XUtOdEmJ6Q3j2dfrv3ryC6NT8/YT4zm5AqtyD2gb/WMAFWQtSX/LQbH8Y ZC04ERP0Ud7udxJsKHScpiZKMjH72jYBVYTi/FCUovGDNBHoWvQ0xAFJuQtOJGrkZMod tVJjuBT5lX7LcdVcZMDUstIiNXYXchj5Irled4JFyXDkVrHYDiGUb6d9Hxw78SZj5uzK z3yTs2nEfcTx9qq6GWVnLbSpDDn5ke/AVipGzO9Zt+Jx9yQDtv74H93lAtfD+1SRd8BC 2/9VZoXMPQhL3YtRq+7UjidkW9HJQp4vPCxoXLOMFQql2hU++kFJthM7j3G3W0Gqn5Mg DNng== X-Gm-Message-State: AD7BkJKQ1JJV3IsorLVQ0okW6xiApOIdCQg+DMwjOe7m3jLJR+LP1RHHK+AXXPekZdJa2A== X-Received: by 10.98.14.147 with SMTP id 19mr5372099pfo.79.1459272347296; Tue, 29 Mar 2016 10:25:47 -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 p75sm44565519pfi.29.2016.03.29.10.25.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Mar 2016 10:25:46 -0700 (PDT) Received: from kamal by fourier with local (Exim 4.86_2) (envelope-from ) id 1akxOj-0000JC-5c; Tue, 29 Mar 2016 10:25:45 -0700 From: Kamal Mostafa To: "David S. Miller" Subject: [4.2.y-ckt stable] Patch "ipv4: Don't do expensive useless work during inetdev destroy." has been added to the 4.2.y-ckt tree Date: Tue, 29 Mar 2016 10:25:44 -0700 Message-Id: <1459272344-1144-1-git-send-email-kamal@canonical.com> X-Mailer: git-send-email 2.7.4 X-Extended-Stable: 4.2 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-4.2.y-queue branch of the 4.2.y-ckt extended stable tree which can be found at: http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-4.2.y-queue This patch is scheduled to be released in version 4.2.8-ckt7. If you, or anyone else, feels it should not be added to this tree, please reply to this email. For more information about the 4.2.y-ckt tree, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable Thanks. -Kamal ---8<------------------------------------------------------------ From d2f3560b0b9555619aa91c85a459215486cada48 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 0420012..eb1ff7c 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 d7116cf..fb963ae 100644 --- a/net/ipv4/fib_frontend.c +++ b/net/ipv4/fib_frontend.c @@ -876,6 +876,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 :-) * @@ -951,6 +954,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); }