https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260831135117.574836-1-sw%40simonwunderlich.de?part=13 [...] > Should a Fixes: tag naming that commit be added? > > Note that this patch depends on the tt_common_entry->flags_lock > infrastructure added earlier in the same series, so a direct stable > backport would need adaptation and the tag would mostly serve > identification. I am not allowed to add Fixes: lines for patches targeting net-next. And this is not suitable for net or stable backports. See https://lore.kernel.org/all/7d73cd74-b040-4a3d-9d78-4ad8fc0a01f4@redhat.com/ > > > diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c > > index 163f90962306..a870d9a97e32 100644 > > --- a/net/batman-adv/translation-table.c > > +++ b/net/batman-adv/translation-table.c > > @@ -333,6 +333,10 @@ static void batadv_tt_local_size_mod(struct batadv_priv *bat_priv, > > * given vid > > * @bat_priv: the bat priv with all the mesh interface information > > * @vid: the VLAN identifier > > + * > > + * It must only be called when removing the NEW flag of a > > + * batadv_tt_local_entry while it is still part of the bat_priv->tt.local_hash. > > + * It must therefore be checked under the specific list_locks[i]. > > */ > > static void batadv_tt_local_size_inc(struct batadv_priv *bat_priv, > > unsigned short vid) > > Discovered by: gpt-5-6-sol, opus-5 ยท Missed by: sashiko-gemini > This is a pre-existing issue and not introduced by this patch, but does > the new invariant ("It must therefore be checked under the specific > list_locks[i]") hold on the removal side as well? > > batadv_tt_local_remove() decides that no batadv_tt_local_size_dec() is > owed while holding only flags_lock, then drops it before unlinking: [...] > Can vlan->tt.num_entries stay inflated by one in that case, the same > "nothing will reduce the counter again" failure mode, reached through > the check side instead of the walk side? Out-of-scope for this specific patch. See patch "batman-adv: tt: decrement count for committed client on local_remove" Regards, Sven