Received: by 10.213.65.68 with SMTP id h4csp1683844imn; Mon, 19 Mar 2018 10:28:29 -0700 (PDT) X-Google-Smtp-Source: AG47ELvhjQn0AjIQYEWnBRwbXPUFxcgYmL8We6533XP96lmhTj9Pnws2NipxQOFv6kh6hS918jPX X-Received: by 10.101.96.142 with SMTP id t14mr9578617pgu.58.1521480509251; Mon, 19 Mar 2018 10:28:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521480509; cv=none; d=google.com; s=arc-20160816; b=VS2AieliO/7rBBffsMzsr4p1O0ZHzHvp70TpSEm0UWsBzabhCQYluttFtLE5XqBG+p TkOmTLRgixyJATOjx2RbK503bfJwr3VU4M31La1v7E7ogU5kLc3BmbdWWOXOEip+eo+Z 1XYlFracVEUb2I7k9e90yZcgdiBLjWKCHoXNGhTgoQB7RM7OGgFlRnYRL3DZU7Jsx3jE udcFOe1pf+1lkImdxCYkwzmXZlpuZEghxm1Dp0ByGD3x0ZuehasF9U0JnSM90H6EFf3M OyGxKRk413+vh+dNCCvX7GXmuYGvShWSVxvoxVaj7vvn5qAA//ZASfESV7rSMLbYjX0k iiFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :spamdiagnosticmetadata:spamdiagnosticoutput:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=D9JLl8JiKl9u0yHbteF8K0ZIrIs0YK0nmJ+AILsajg4=; b=SP4v2sNBLONJPOmkTckHdmQkSqrz51/garYfqUb9Gs+pk14EwKcXgCQSbgUKNZzNqs QoDAgZC+UwF4LCxGiu3S+OTLL7S7mRVCfRK3P6gHrIeFEH2OFB7JfIhe0I/8GDCM8B86 ijjSG90p50Dx5XVwvAzYTnQXHlv+jNIRFJ3wzVNUqy+Bw93iqIzZP8OULKR3MO3oKfzu jWPGMm0nG9D1CabLJPiquiTOz3I3AmEft7/kHWlgRzApe+jUTFnW7G5hJRwopZW2dK39 QxmsPV6atHSFeWicUAsHtw/ACLa02c9zCK7r/uyHudJjqkRdvqylJLZLGCef185Xzx4v gajw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@microsoft.com header.s=selector1 header.b=kQBpgkRJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=microsoft.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z4si237317pgp.319.2018.03.19.10.28.14; Mon, 19 Mar 2018 10:28:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@microsoft.com header.s=selector1 header.b=kQBpgkRJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966275AbeCSQIR (ORCPT + 99 others); Mon, 19 Mar 2018 12:08:17 -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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=D9JLl8JiKl9u0yHbteF8K0ZIrIs0YK0nmJ+AILsajg4=; b=kQBpgkRJrtU+j7HLJe2pVxs7iNAWIRGJuo9jxM+YxY5Ux7MFbNd3P7DlHCpwXzsYCpcK2lm4Ew5NesTwQatskn1CklhsyFBA04zSslvaZ61xHQB/yNGVOesg7QztkM4Jc49TTqx9nh5j+8btfXYoo4qVy7lUfF/28BTICzRfc5c= Received: from DM5PR2101MB1032.namprd21.prod.outlook.com (52.132.128.13) by DM5PR2101MB0805.namprd21.prod.outlook.com (10.167.105.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.631.2; Mon, 19 Mar 2018 16:08:09 +0000 Received: from DM5PR2101MB1032.namprd21.prod.outlook.com ([fe80::3d9b:79e7:94eb:5d62]) by DM5PR2101MB1032.namprd21.prod.outlook.com ([fe80::3d9b:79e7:94eb:5d62%5]) with mapi id 15.20.0631.004; Mon, 19 Mar 2018 16:08:09 +0000 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; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) 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: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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