From patchwork Thu Aug 17 00:02:51 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mahesh Bandewar X-Patchwork-Id: 802277 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=bandewar-net.20150623.gappssmtp.com header.i=@bandewar-net.20150623.gappssmtp.com header.b="1yYp+TXo"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3xXmd60GZkz9t32 for ; Thu, 17 Aug 2017 10:03:05 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751500AbdHQADA (ORCPT ); Wed, 16 Aug 2017 20:03:00 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:36539 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751119AbdHQAC7 (ORCPT ); Wed, 16 Aug 2017 20:02:59 -0400 Received: by mail-pg0-f67.google.com with SMTP id y129so6925078pgy.3 for ; Wed, 16 Aug 2017 17:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bandewar-net.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=EnxbExPMCS1xCWpp1l5kKBnzho2njJv0EKxMnT91y70=; b=1yYp+TXodPTWc43Ubgo2Q/kMErz3xLfxL5W8l9SNTfDZzIRaim6Fpw7Hr7+ucWAzkq kBW7PjjXEwx89xkv5q97vIXW3B4uHFLLQi4mj5Ye4MWfHB/txoYmIqMsZF8+2h9xbjiI YnJ0W6eHtG0JB6enC7BLB1fQzALN2WkVwTrmEkYMZk89u5RFyQjo8s9fuisFDB7SCLMk wDY1hbXf+NkjxEmPh0KJ1+rkwUmdsLIKhbvwxA33CCzbdsHut1N3jSOKFe5inE9llw3g pWtg6M2JfoFzRyBBkVV5SE2iHRwNL+ZtdDQJdAhPTzyNT4KusEejAdaymQZLnU8CvSE5 tXkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=EnxbExPMCS1xCWpp1l5kKBnzho2njJv0EKxMnT91y70=; b=XsrbYiVtV59zJ1PFfRfNChwGTV7rb32LysEHr5WA9hdZccnYuu2iaRVq49PKycQ63L 0z2oxUf6Hgg6+C29C37wEtu0FIW4I53oQg8fWHHm9rIBh70pvfx7AvG0trSdTdfvy03N powojt9s67daUOlt9pVyT8YHULYvpyXz8hcwI6IPjeQiIQcXhgQLU3nv90UyJhV16t/5 rhKKPL/mxH0XTrmNpRyzjOT33CCkciIRxcOd6bRdXhjHsypC1u15ipzRyuCOWjzzk/U/ gb4ioQ8DB6GLCKm+kKpnj2mnuV3C4jlbh7AHRFJgJC4o4TIvcH7Y4bU0mQicPUbzHxY1 iABQ== X-Gm-Message-State: AHYfb5g/L9nUQzcZf39UJt2REKdeLIxzHGOL9BJtLb5kz4+IWtLZmVcv snwIOPW3t5PcWgjv X-Received: by 10.98.214.145 with SMTP id a17mr3394364pfl.148.1502928178703; Wed, 16 Aug 2017 17:02:58 -0700 (PDT) Received: from localhost ([2620:15c:2cb:201:30c3:fe0b:a558:4dad]) by smtp.gmail.com with ESMTPSA id t22sm3589383pfi.68.2017.08.16.17.02.57 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 16 Aug 2017 17:02:58 -0700 (PDT) From: Mahesh Bandewar To: David Miller Cc: Eric Dumazet , netdev , Mahesh Bandewar , Ido Schimmel , Hans Liljestrand , Kees Cook , Reshetova Elena , Sowmini Varadhan , Florian Westphal , Roopa Prabhu , Ihar Hrachyshka , David Ahern , Zhang Shengju , Mahesh Bandewar Subject: [PATCH next] neigh: initialize neigh entry correctly during arp processing Date: Wed, 16 Aug 2017 17:02:51 -0700 Message-Id: <20170817000251.38469-1-mahesh@bandewar.net> X-Mailer: git-send-email 2.14.1.480.gb18f417b89-goog Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Mahesh Bandewar If the ARP processing creates a neigh entry, it's immediately marked as STALE without timer and stays that way in that state as long as host do not send traffic to that neighbour. I observed this on hosts which are in IPv6 environment, where there is very little to no IPv4 traffic and neigh-entries are stuck in STALE mode. Ideally, the host should have PROBEd these neighbours before it can send the first packet out. It happens as a result of following call sequence in an environment where host is mostly quiet as far as IPv4 traffic but few connected hosts/gateways are sending ARPs. arp_process() neigh_event_ns() neigh_lookup() neigh_create() neigh_alloc() nud_state=NUD_NONE neigh_update(nud_state=NUD_STALE) In the above scenario, the neighbour entry does not get a chance to get PROBEd as subsequent call to neigh_update() marks this entry STALE. This patch initializes the neigh-entry correctly if it was created as a result of neigh_lookup instead of just updating it in neigh_event_ns() right after creating it. Signed-off-by: Mahesh Bandewar --- net/core/neighbour.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 16a1a4c4eb57..d8a35db6c43b 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -1300,9 +1300,13 @@ struct neighbour *neigh_event_ns(struct neigh_table *tbl, { struct neighbour *neigh = __neigh_lookup(tbl, saddr, dev, lladdr || !dev->addr_len); - if (neigh) - neigh_update(neigh, lladdr, NUD_STALE, - NEIGH_UPDATE_F_OVERRIDE, 0); + if (neigh) { + if (neigh->nud_state & NUD_VALID) + neigh_update(neigh, lladdr, NUD_STALE, + NEIGH_UPDATE_F_OVERRIDE, 0); + else + neigh_event_send(neigh, NULL); + } return neigh; } EXPORT_SYMBOL(neigh_event_ns);