Re: [PATCH net-next 13/15] batman-adv: tt: transition NEW local entries only under lock

[Sven Eckelmann <sven@narfation.org>]

[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]