Thread (13 messages) 13 messages, 4 authors, 2026-09-18

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 '---'.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help