https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260907081824.2474040-1-sw%40simonwunderlich.de?part=11


[...]
> Discovered by: opus-5 · Missed by: opus-4-7, gpt-5-6-sol, sashiko-gemini · Confirmed by: gpt-5-6-sol
> Is the "was never announced" wording in this new kernel doc a bit too
> strong?  The body of the same function documents the opposite case a few
> lines later:
> 
> net/batman-adv/translation-table.c:batadv_tt_local_remove_now() {
> 	/* batadv_tt_local_transition_new() may have committed the entry and
> 	 * thus counted it in the local table size since the
> 	 * BATADV_TT_CLIENT_NEW check in batadv_tt_local_mark_removed().
> 	 */
> 	if (!(batadv_tt_flags_get(common) & BATADV_TT_CLIENT_NEW))
> 		batadv_tt_local_size_dec(bat_priv, common->vid);
> }
> 
> batadv_tt_local_mark_removed() drops common->flags_lock before returning
> and batadv_tt_local_remove() holds no other lock, while
> batadv_tt_local_transition_new() only holds the local list_lock and
> flags_lock:
> 
> batadv_tt_local_commit_changes_nolock()
>   batadv_tt_local_transition_new()   /* clears BATADV_TT_CLIENT_NEW,
>                                         batadv_tt_local_size_inc() */
>   batadv_tt_local_update_crc()
>   atomic_inc(&bat_priv->tt.vn)
> 
> So in that window the entry can be committed, counted and announced under
> the current ttvn, and batadv_tt_local_remove_now() still unlinks it from
> bat_priv->tt.local_hash instead of leaving it BATADV_TT_CLIENT_PENDING
> until the next ttvn increment, as described by
> batadv_tt_local_set_pending_event():
> 
>  * Schedule the TT change announcement for the entry. The entry is kept in the
>  * local table until the next TTVN increment so that a consistency-check
>  * response can still be answered.
> 
> Would it make sense either to soften the new kernel doc (and the matching
> sentence in the commit message, "A client which was added after the last
> ttvn increment was never announced and can be dropped from the local table
> right away") to mention that the entry may already have been committed, or
> to fall back to the pending path when the NEW flag turns out to be cleared?

See https://patchwork.open-mesh.org/project/b.a.t.m.a.n./patch/20260908-sashiko-kdoc-v1-3-535b498f2519@narfation.org/

Regards,
	Sven