Re: [PATCH net-next 11/15] batman-adv: tt: extract immediate purge of a local entry
flat view
From: Sven Eckelmann <sven@narfation.org>
Date: 2026-09-08 17:27:54
Also in:
batman
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
Attachments
- signature.asc [application/pgp-signature] 228 bytes