From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6C3C74AC141 for ; Thu, 17 Sep 2026 20:26:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789676804; cv=none; b=kbhUZM3GgiBUN6tz1fL103W/Fh+z6SyhEBQ4iYYglNie+e4TLkiWeJqCsW9nR1tgoeP3Df7v5QYex2buuCXzBCAzSGZCSW+dWJl3hvm6tMRgLMYqsADwiXOkH3J58Kl4vR/YonVHRISeXzsxdSWZlL/RnMo4+qmcg+XSVCnFRIE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789676804; c=relaxed/simple; bh=/wm6upxZhNKjCNldD9EE0n5yIdNuPgK9lrIwGU6QUEc=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=lNsLj7UzrpoAQqh8JP+KreZXPNGB3R1u2Q/hS20OUzoSpnHVIo8I2WlmzPec9WmmmrntRTCmClbzQD4rZBDtTpg00v6TScUNJT5YVIyy1xzNJRzcZOgCatsiJ93d6FIUZLjWuqq0mmb61XA57t4w+aKtiGAZ5QU/HEepoafb7kQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Yi6MDRhJ; arc=none smtp.client-ip=209.85.214.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Yi6MDRhJ" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2caced6038eso11358285ad.0 for ; Thu, 17 Sep 2026 13:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789676802; x=1790281602; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=cSGFqbf3XjQKoM9IeVQurnJH7q0lWkBYjjfyEjg57UQ=; b=Yi6MDRhJ9LrvWVAkj858t/31R0nZadrF8vfYStOZG6VVyMneMCehw1cRw5T1Ukg2If c6/LHD1Rt9lbG6IlNFhtXa69i8tWPEYRQxfT2z4DrU1AKEejkn9mlVbRUADkQno0ixiD zHCMLkudWX7+7bM1IroDrKu9LWJlrr4tO7+P7xZDnVnfQwB+qJAl9oE5GLtk4RkaEK2P dTn27ty04JD/u5DcpT0EE39WRj9GQG0QeRw008o8tJuL6aCMbJv9G8aai/sH0NZpO142 51QUNNOYC5rwN42gTi8hK8/HWiRsgmalboFahfbRy/h9m/EiDCVKWC6U6mjXdkEgkjET vgIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789676802; x=1790281602; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=cSGFqbf3XjQKoM9IeVQurnJH7q0lWkBYjjfyEjg57UQ=; b=RoLIAr8hzjOzanWKZfKkSEtJ4KZ3ApxXbBOVtvhYL8pINgf2QJPvP0j4kp+M7DH+3i DssAe+6z6YYfzEfv+ikd7orfxl9zCxsltS2flWpo+9nJqlU+ZLHjpYCPPanlhlH31+GT u51miNqDNXpPaPMRDAfNS7AaCYZOVsRJyPDdD20lq/NOsrVeRcO0R/rANuStIKaDnNh1 Frc+p+kAHxhOYilmt/hWBOuT7hLoEWph2fCioIo2cE9Y3DzJcH41VaU2CgoX04XfOqBM JYZBL9G2XXvd4adp7dg1IenFA1LXH+9IMNS/jJklogVv4P7O2ID7kjZ+vTV3ASYrwK9W gipQ== X-Forwarded-Encrypted: i=1; AKwUvBx9sHNKqPLkX6GDevCzvLobtI0VgR0vzX2vQxv0K2/MsLygWB93Mx5ZT/07AiIVZPnyw5CYCI2RQ3sutBA=@vger.kernel.org X-Gm-Message-State: AFuF++mFz8LIQqgrsjOMQI8n0UrQzjZAy2CcjA6bvvY3TB3TNGMrywuM zcC37TeK2EHXH4J4GtQF9VXMaW4s8S0pAvX+TrfQR3GzLizEdoHLj8Ve X-Gm-Gg: AYBFou1f0YMBRexZlnXID6Xb8DgwzNLasqrBT9HH68jovVzuKzZ9uJXKGW9Jt6Y7saS OwVAWasYH4Nu1F2L+T48mH8A9LDeSiY4GGAPAa0GURl7bbqLa/dyc1yxplUK/VlCX/GWmE2pv8t 5r12ckdsmCg329yZTwOznHlzMysiCyF/Ggpf4s+mjMA4JqLZv4JPWov2Cf5KOYJzObTDjqNVa6q lzuZLZcfpZTN0s8X3RUZyfg9msmjwHDbUb6kbNPjfaIXbAXplUPJLO6eP4SKa6EPzY6CbPLE6YY CWo1aWtV24nFbtoBVcI6tcaRuioRED4G9Wxc8DrxiaisqrGn5FEM3Oc2w+YjdUXvJeaeaHo0TGV CSvNpeOMZBk1drxnUkdXXuVuQqra8vYunkojq3/JiOybmatL9ROcitekz02GLGZ96aRJirr3XS1 m3a2csAl6agmJw9+ubt8Wibzn1jgqUS8UlysXQlg2e/IvKGIFeVl+k/Wn62g3qxZ5xchyRHesIP TCgkS1pu5eBxixq4+lqhnZb4cwzro47WatPfA== X-Received: by 2002:a17:903:1a4e:b0:2d8:d4d2:d13a with SMTP id d9443c01a7336-2dd9ca3f373mr62050225ad.22.1789676801756; Thu, 17 Sep 2026 13:26:41 -0700 (PDT) Received: from localhost ([13.93.150.60]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-33bf5a93f1fsm17829614eec.11.2026.09.17.13.26.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2026 13:26:41 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 17 Sep 2026 20:26:39 +0000 Message-Id: Cc: , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH net-next v2 1/2] ipv6: update NUD_FAILED neighbors from NA messages From: "Lawrence Lee" To: X-Mailer: aerc 0.17.0 References: <6596966f734f3d416bfa83722f7a595149bcc3f8.1789448374.git.lfqlee314@gmail.com> <178966456087.22033.11671220306303617581@kernel.org> In-Reply-To: <178966456087.22033.11671220306303617581@kernel.org> On Thu Sep 17, 2026 at 5:02 PM UTC, wrote: > > diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c > > index 90cd5d8525698..84d70c09205a2 100644 > > --- a/net/ipv6/ndisc.c > > +++ b/net/ipv6/ndisc.c > > [ ... ] > > > @@ -972,14 +982,18 @@ static enum skb_drop_reason ndisc_recv_ns(struct = sk_buff *skb) > > =20 > > static int accept_untracked_na(struct inet6_dev *idev, struct in6_addr= *saddr) > > { > > + /* For any given neighbor IP address, consider it an untracked nei= ghbor if > > + * it is absent from the neighbor cache or if it has a NUD_FAILED = entry in > > + * the neighbor cache > > + */ > ^^^^ > > [Severity: Low] > This isn't a bug, but this comment block in accept_untracked_na() is > indented with spaces while the switch statement right below it uses tabs, > so checkpatch reports "ERROR: code indent should use tabs where possible"= . > > The comment also describes what the caller considers "untracked", based o= n > the neighbour cache, but accept_untracked_na() only reads the sysctl valu= e > and never sees the neighbour entry. Would it fit better next to > > neigh_untracked =3D !neigh || neigh_failed; > > in ndisc_recv_na(), where the RFC 9131 decision table already documents t= he > same concept? This comment will be removed as per maintainer feedback. > [Severity: Low] > Is the new FAILED handling covered by an in-tree test at this point in th= e > series? As of this commit, ndisc_unsolicited_na_test.sh and > arp_ndisc_untracked_subnets.sh only seed absent entries, so the whole > FAILED to STALE half of the knob, including the mode 2 same-subnet > qualification, would still pass if it were broken. > > For the record, this looks resolved later in the same series: the follow-= up > patch "selftests: net: test untracked NA recovery of FAILED neighbors" > (7be3b5fcfd3f9adb7489aff8013c6d4beacbf20c) seeds entries with > > ip neigh replace ... nud failed extern_learn > > and adds the failed combinations covering every row of the new table, > including the in-prefix and out-of-prefix mode 2 cases. Mentioning it her= e > only for completeness. > The tests are added in the next patch of this series > [Severity: Medium] > Why does the gateway address handed to rt6_clean_tohost() now depend on t= he > previous NUD state of the entry? Before this patch the same "router to > host" event always flushed routes keyed by saddr. > > fib6_clean_tohost() in net/ipv6/route.c matches the argument against the > gateway of RA-installed routes and against cached exceptions: > > if (((rt->fib6_flags & RTF_RA_ROUTER) =3D=3D RTF_RA_ROUTER) && > nh->fib_nh_gw_family && ipv6_addr_equal(gateway, &nh->fib_nh_gw6)) > return -1; > > so it expects the address of the node that stopped being a router, which = is > unrelated to whether the cache entry happened to be in NUD_FAILED. > > When saddr differs from msg->target, and that is allowed since RFC 4861 4= .4 > only requires the NA source to be an address of the sending interface (a > router advertising a global target from its link-local source, or the pro= xy > NA case handled a few lines above via pneigh_lookup()), the FAILED recove= ry > path flushes routes keyed by msg->target while every other path flushes > routes keyed by saddr. Can both be right for the identical event? > > If saddr was the wrong key all along, would it make sense to fix that > separately for all cases, with a Fixes: tag, rather than changing it only > for the FAILED path? The changelog describes only the FAILED to STALE > transition and does not mention this change of key. This change will be removed in the next version of the series as=20 discussed in another thread:=20 https://lore.kernel.org/all/DLHV5GF21AY4.3GAK241ZI2UR8@gmail.com/