On Thursday, 1 October 2026 12:10:28 CEST netdev-bot+sashiko@kernel.org wrote:
[...]
> [Severity: Low]
> 
> This isn't a runtime bug, but should this have a Fixes: tag?
> 
> The problem seems to come from bbfb0d2cf035 ("batman-adv: tt: remove only
> the entry which was looked up from the hash"). That commit changed the
> unlink in batadv_tt_local_remove() from batadv_compare_tt to
> batadv_compare_tt_entry. It kept the unconditional delete event in front
> of the unlink.

No, this is not causing the "problem" and was there since a very long time. 
And the change is not suitable for stable backports. And since it is submitted 
for net-next, I am not allowed to add Fixes: or Cc: stable@ tags.

[...] 
> [Severity: High]
> 
> Does this reordering open a new window in which a replacement entry's add
> event gets dropped?
[...]
> 
> Could the delete event instead be queued inside the same bucket list_lock
> critical section as the unlink, and only when this exact object was
> found? batadv_tt_local_set_pending() in "batman-adv: tt: queue local DEL
> event under bucket lock" already takes list_lock and then
> changes_list_lock in that order.
> 
> [ ... ]
> 
> 

Noted in https://www.open-mesh.org/issues/475 as potential further work to 
harden the code path further.

Regards,
	Sven