From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-3230508-1521475710-2-9339599720498066829 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, HEADER_FROM_DIFFERENT_DOMAINS 0.25, RCVD_IN_DNSWL_HI -5, T_RP_MATCHES_RCVD -0.01, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.132.180.67', Host='vger.kernel.org', Country='CN', FromHeader='com', MailFrom='org', XOriginatingCountry='US' X-Spam-charsets: plain='iso-8859-1' X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: stable-owner@vger.kernel.org ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=arctest; t=1521475709; b=WHvCSjyKp1yQ11gN3fe3scR6HmDPec7mim8qeRaIyo93PPZ V7y9WTIcex0JE9itGn2MmzWTWkkt7wRjasYCIuwAfbq8sOKXvw2X3UVeSEbYI4Za MByk5kSPKQmhOIMLyu5zgeAHoWedAa/qXCbJIRVleIryh/DnGohPYUmr/yPG/ROo rMWKP40sgNMgeafPL3f01t88wZtQRtY2CQrFM73/RCa6F3+2HtD7APtuVNN7HBcd 00LQoXkBCdVCng19WuzIhHaMQFGYaY2u+ASgavoJVqR+e3hTDrcHyqWGLvyhH7wU qT+T8++bdy5+iK+WgHddhILKqRRVzD/sD/PM33Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=from:to:cc:subject:date:message-id :references:in-reply-to:content-type:content-transfer-encoding :mime-version:sender:list-id; s=arctest; t=1521475709; bh=D9JLl8 JiKl9u0yHbteF8K0ZIrIs0YK0nmJ+AILsajg4=; b=UIQ2w+G6JqWgwgqL9J3SnX 8htpRJy9NZA9cL3zFOc3T4Jta14siXID5d2jgSys418FXsx029E5Ox8H7u4iQZ3d RMkkRUxk6itgMFMpVZqzeiUyPFx4jiS5+Idy35p3Zah92s3QWHCQGbzqLZVQCAs9 dY+NBQUaEQBQ7iTtolUuGz/xdck4UUOZK+/PlZP/4VkzUlG33sZ29Gvi4NKL0lgE guWbaHeRgXbjIfDmQ0e+Y4Eem5E/M5GLVPWff+n1fmixQznj9yINPs5fnyU3uMpl TA5woDw6T43fYjBw/4vU8ZoEIWxzdwgalawlxhZ890RRo1Et2FkBinSRtmWSoP8g == ARC-Authentication-Results: i=1; mx2.messagingengine.com; arc=none (no signatures found); dkim=pass (1024-bit rsa key sha256) header.d=microsoft.com header.i=@microsoft.com header.b=kQBpgkRJ x-bits=1024 x-keytype=rsa x-algorithm=sha256 x-selector=selector1; dmarc=pass (p=reject,has-list-id=yes,d=none) header.from=microsoft.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=stable-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-category=clean score=-100 state=0 spamcause=gggruggvucftvghtrhhoucdtuddrgedtgedrudefgdekheculddtuddrgedtfedrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhtfffkfhgjihgtgfggshhpjeesthhqredttddtudenucfhrhhomhepufgrshhhrgcunfgvvhhinhcuoeetlhgvgigrnhguvghrrdfnvghvihhnsehmihgtrhhoshhofhhtrdgtohhmqeenucfkphepvddtledrudefvddrudektddrieejpdehvddrudeikedrheegrddvhedvpdhfvgektdemmeefugelsgemjeelvgejmeelgegvsgemheguiedvnecurfgrrhgrmhepihhnvghtpedvtdelrddufedvrddukedtrdeijedphhgvlhhopehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhmrghilhhfrhhomhepoehsthgrsghlvgdqohifnhgvrhesvhhgvghrrdhkvghrnhgvlhdrohhrghequceuqfffjgepkeeukffvoffkoffgucfukfgkgfepuddtvddtudenucevlhhushhtvghrufhiiigvpeeftd; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=microsoft.com header.result=pass header_is_org_domain=yes Authentication-Results: mx2.messagingengine.com; arc=none (no signatures found); dkim=pass (1024-bit rsa key sha256) header.d=microsoft.com header.i=@microsoft.com header.b=kQBpgkRJ x-bits=1024 x-keytype=rsa x-algorithm=sha256 x-selector=selector1; dmarc=pass (p=reject,has-list-id=yes,d=none) header.from=microsoft.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=stable-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-category=clean score=-100 state=0 spamcause=gggruggvucftvghtrhhoucdtuddrgedtgedrudefgdekheculddtuddrgedtfedrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhtfffkfhgjihgtgfggshhpjeesthhqredttddtudenucfhrhhomhepufgrshhhrgcunfgvvhhinhcuoeetlhgvgigrnhguvghrrdfnvghvihhnsehmihgtrhhoshhofhhtrdgtohhmqeenucfkphepvddtledrudefvddrudektddrieejpdehvddrudeikedrheegrddvhedvpdhfvgektdemmeefugelsgemjeelvgejmeelgegvsgemheguiedvnecurfgrrhgrmhepihhnvghtpedvtdelrddufedvrddukedtrdeijedphhgvlhhopehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhmrghilhhfrhhomhepoehsthgrsghlvgdqohifnhgvrhesvhhgvghrrdhkvghrnhgvlhdrohhrghequceuqfffjgepkeeukffvoffkoffgucfukfgkgfepuddtvddtudenucevlhhushhtvghrufhiiigvpeeftd; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=microsoft.com header.result=pass header_is_org_domain=yes Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966267AbeCSQIP (ORCPT ); Mon, 19 Mar 2018 12:08:15 -0400 Received: from mail-dm3nam03on0098.outbound.protection.outlook.com ([104.47.41.98]:60247 "EHLO NAM03-DM3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S966200AbeCSQIM (ORCPT ); Mon, 19 Mar 2018 12:08:12 -0400 From: Sasha Levin To: "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" CC: Ihar Hrachyshka , "David S . Miller" , Sasha Levin Subject: [PATCH AUTOSEL for 4.4 042/167] neighbour: update neigh timestamps iff update is effective Thread-Topic: [PATCH AUTOSEL for 4.4 042/167] neighbour: update neigh timestamps iff update is effective Thread-Index: AQHTv5w0Mx7F4Sc9SEOUK9phEHiJ1g== Date: Mon, 19 Mar 2018 16:06:13 +0000 Message-ID: <20180319160513.16384-42-alexander.levin@microsoft.com> References: <20180319160513.16384-1-alexander.levin@microsoft.com> In-Reply-To: <20180319160513.16384-1-alexander.levin@microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [52.168.54.252] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DM5PR2101MB0805;7:B6DeghUcXEUm0aWwxaIN4hAyOGsaOqEyyfMiU5O9t1pcrfi71QFk6aKyYtXnNWn6rOOCPSqFy4H2MVOhv4o6BFQ0e90G309AQXEyJSvI0ejpfPHFMtWYuf72O2icWCt3iu71lf/UxUw6HznORfSxpr4mcwezEQM5BUthGu7y0Kb8uxO4kxX/XL1BUwmXVdcO15IdCYUz/PbdGDIPGD0M9Rd7Wynp5eZO56z172+g4N9AXNnmKGVPCtkDFEENq+Nw;20:oa+eFuOPAeF9oPOfLugGzdWUlREi1nUycF36EqM7MukbV2nNs6Mzvpll+3dWhEtQMJk6eD76xW64C1Zu0LUynPjPOKTwsRO7A/ApJlzmWumvIyZdsE7TC3cJsYRqZJlq8y9REnlcsNdyXKXLiti2Ygf3Xh4LxKfIFvprgR1qI7g= x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c822a71f-affe-401e-8707-08d58db39bed x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020);SRVR:DM5PR2101MB0805; x-ms-traffictypediagnostic: DM5PR2101MB0805: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Levin@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231221)(944501300)(52105095)(3002001)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011);SRVR:DM5PR2101MB0805;BCL:0;PCL:0;RULEID:;SRVR:DM5PR2101MB0805; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(39380400002)(376002)(346002)(366004)(396003)(39860400002)(199004)(189003)(2950100002)(305945005)(186003)(86362001)(6506007)(3660700001)(6666003)(5660300001)(6116002)(8936002)(3846002)(1076002)(26005)(7736002)(6486002)(2900100001)(6436002)(2906002)(86612001)(68736007)(81166006)(81156014)(10090500001)(15650500001)(102836004)(59450400001)(8676002)(14454004)(105586002)(107886003)(25786009)(478600001)(2501003)(5250100002)(53936002)(3280700002)(316002)(54906003)(4326008)(6512007)(72206003)(66066001)(22452003)(10290500003)(99286004)(76176011)(36756003)(97736004)(106356001)(110136005)(22906009)(217873001);DIR:OUT;SFP:1102;SCL:1;SRVR:DM5PR2101MB0805;H:DM5PR2101MB1032.namprd21.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; x-microsoft-antispam-message-info: oIizZBbxaQI/Qn9kqks63D/QuQeVvuyTw5LseSDCXPBLQc/i1skJMFNoFw2ACCcRhwowANikGpDDe6pYtsytJvDlXMRywBpxnc0YkP7YjYrk1YbUVvWgv4Ikvvp4Fwd3pm9NRod2WPPmr5oN85zn9YFcKyQ4vn2sIZO1L0yp2uuLI4FRNbw9PpNPzRdu3/luCesUmtlD3OH0Ajswjq2TX/aKNUpcwmwakVJOFCfu9XCaQtvLTfdxLuDjdbl0TU1nVZxL+gInR/fTX0Le9p8ZFSvXxRARq9tOd9W0oiM8Ml3Y3gWkJCvKAHROFt3tvEVadcvQNw3oWJXjrKWVCAt4HQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c822a71f-affe-401e-8707-08d58db39bed X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2018 16:06:13.8729 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0805 Sender: stable-owner@vger.kernel.org X-Mailing-List: stable@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: From: Ihar Hrachyshka [ Upstream commit 77d7123342dcf6442341b67816321d71da8b2b16 ] It's a common practice to send gratuitous ARPs after moving an IP address to another device to speed up healing of a service. To fulfill service availability constraints, the timing of network peers updating their caches to point to a new location of an IP address can be particularly important. Sometimes neigh_update calls won't touch neither lladdr nor state, for example if an update arrives in locktime interval. The neigh->updated value is tested by the protocol specific neigh code, which in turn will influence whether NEIGH_UPDATE_F_OVERRIDE gets set in the call to neigh_update() or not. As a result, we may effectively ignore the update request, bailing out of touching the neigh entry, except that we still bump its timestamps inside neigh_update. This may be a problem for updates arriving in quick succession. For example, consider the following scenario: A service is moved to another device with its IP address. The new device sends three gratuitous ARP requests into the network with ~1 seconds interval between them. Just before the first request arrives to one of network peer nodes, its neigh entry for the IP address transitions from STALE to DELAY. This transition, among other things, updates neigh->updated. Once the kernel receives the first gratuitous ARP, it ignores it because its arrival time is inside the locktime interval. The kernel still bumps neigh->updated. Then the second gratuitous ARP request arrives, and it's also ignored because it's still in the (new) locktime interval. Same happens for the third request. The node eventually heals itself (after delay_first_probe_time seconds since the initial transition to DELAY state), but it just wasted some time and require a new ARP request/reply round trip. This unfortunate behaviour both puts more load on the network, as well as reduces service availability. This patch changes neigh_update so that it bumps neigh->updated (as well as neigh->confirmed) only once we are sure that either lladdr or entry state will change). In the scenario described above, it means that the second gratuitous ARP request will actually update the entry lladdr. Ideally, we would update the neigh entry on the very first gratuitous ARP request. The locktime mechanism is designed to ignore ARP updates in a short timeframe after a previous ARP update was honoured by the kernel layer. This would require tracking timestamps for state transitions separately from timestamps when actual updates are received. This would probably involve changes in neighbour struct. Therefore, the patch doesn't tackle the issue of the first gratuitous APR ignored, leaving it for a follow-up. Signed-off-by: Ihar Hrachyshka Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- net/core/neighbour.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 253c86b78ff0..33432e64804c 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -1132,10 +1132,6 @@ int neigh_update(struct neighbour *neigh, const u8 *= lladdr, u8 new, lladdr =3D neigh->ha; } =20 - if (new & NUD_CONNECTED) - neigh->confirmed =3D jiffies; - neigh->updated =3D jiffies; - /* If entry was valid and address is not changed, do not change entry state, if new one is STALE. */ @@ -1159,6 +1155,16 @@ int neigh_update(struct neighbour *neigh, const u8 *= lladdr, u8 new, } } =20 + /* Update timestamps only once we know we will make a change to the + * neighbour entry. Otherwise we risk to move the locktime window with + * noop updates and ignore relevant ARP updates. + */ + if (new !=3D old || lladdr !=3D neigh->ha) { + if (new & NUD_CONNECTED) + neigh->confirmed =3D jiffies; + neigh->updated =3D jiffies; + } + if (new !=3D old) { neigh_del_timer(neigh); if (new & NUD_PROBE) --=20 2.14.1