Open-Mesh » batman-adv

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

This isn't a bug introduced by this patch either, but is the caller side of
batadv_tt_global_free() still racy in a way the identity compare cannot
help with? batadv_tt_global_del() tests the orig_list emptiness after
batadv_tt_global_del_orig_node() has already dropped
tt_global_entry->list_lock:

         batadv_tt_global_del_orig_node(bat_priv, tt_global_entry,
                            orig_node, message);

         if (hlist_empty(&tt_global_entry->orig_list))
             batadv_tt_global_free(bat_priv, tt_global_entry,
                           message);

Meanwhile batadv_tt_global_orig_entry_add() can add an originator for the
very same object under that lock:

     spin_lock_bh(&tt_global->list_lock);
     ...
     hlist_add_head_rcu(&orig_entry->list, &tt_global->orig_list);
     atomic_inc(&tt_global->orig_list_count);

Since the emptiness decision and the hash removal are not atomic, can a
global entry that has just regained a valid originator still be unlinked?
The new comparator matches here because it is the same object. The
hlist_empty() read also happens outside the lock that the orig_list is
documented to be protected by.