Re: [PATCH net-next v2 1/2] ipv6: update NUD_FAILED neighbors from NA messages
flat view
From: Ido Schimmel <idosch@nvidia.com>
Date: 2026-09-17 14:38:16
Also in:
linux-bluetooth, linux-doc, linux-kselftest, lkml
On Wed, Sep 16, 2026 at 05:43:11PM +0000, Lawrence Lee wrote:
On Wed Sep 16, 2026 at 12:02 PM UTC, Ido Schimmel wrote:quoted
I'm not sure why you added these lowpan changes to the patch. They are not described in the commit message. Given that lowpan_ndisc_update() already has a TODO comment about only handling overrides, I suggest to ignore it. If needed, it can be modified in the future by someone who can explain the use case and test the change.I added the lowpan changes after my local Sashiko review run identified an issue where a FAILED neighbor can retain an outdated private short address if it's moved to STALE by a non-override NA. Happy to drop all lowpan-related changes or update comments/commit message to reflect the changes, please let me know your preference.
And if the entry is INCOMPLETE and we get a non-override NA? lowpan_ndisc_update() will ignore it. It's a pre-existing issue and there is a TODO comment about this: "/* react on overrides only. TODO check if this is really right. */" You can mention that it's a pre-existing issue under the '---'. That way, hopefully, Sashiko will not flag it and it won't clutter the git log. [...]
Was originally unsure if I should modify the existing logical structure. Thanks for the suggestion, will implement this. Is it appropriate to credit you with a commit tag?
No. I will add my R-b tag when appropriate. [...]
quoted
What is the reason for this change? It's also not explained in the commit message and I suspect it's not needed.This was added in response to another Sashiko local review finding. Let's say we have some FAILED neighbor T with NTF_ROUTER set. If we get an NA from source address S with target address T and with the Router bit clear, existing kernel code will cleanup routes with gateway S, but IMO we should clean routes with gateway T instead since that is the neighbor which was updated by the NA. I can either update comments/commit message to reflect this or remove the change entirely, please let me know your preference.
And if the neighbour was in a different state than FAILED? It seems like another pre-existing issue. I guess that in practice, most of the time, the source address of the NA is also the target address in the payload. You can mention this under the '---'.