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

[...]
> Discovered by: opus-5 · Missed by: sonnet-5, gpt-5-6-sol, sashiko-gemini · Confirmed by: gpt-5-6-sol
> 
> This isn't a regression introduced by this patch, but since the commit
> message names the missing rehashing as the reason for the change, is there
> a plan to address the underlying problem in
> batadv_bla_update_orig_address()?

See https://www.open-mesh.org/issues/452

[...]
> Discovered by: opus-5 · Missed by: sonnet-5, gpt-5-6-sol, sashiko-gemini · Confirmed by: gpt-5-6-sol
> 
> Also pre-existing rather than caused by this patch: the 6 byte
> ether_addr_copy() into backbone_gw->orig is not a single atomic store, and
> batadv_bla_purge_claims() reads that same field under rcu_read_lock() and
> forwards the pointer straight into batadv_handle_unclaim():
> 
> net/batman-adv/bridge_loop_avoidance.c:batadv_bla_purge_claims() {
> 	...
> 			batadv_handle_unclaim(bat_priv, primary_if,
> 					      backbone_gw->orig,
> 					      claim->addr, claim->vid);
> 	...
> }
> 
> After this patch the batadv_compare_eth(backbone_addr,
> primary_if->net_dev->dev_addr) test is the only remaining decision in
> batadv_handle_unclaim(), because the claim is now removed unconditionally.
> Can a reader that observes a mix of the old and new MAC bytes here wrongly
> skip, or wrongly inject, the local UNCLAIM frame while the claim is deleted
> either way?

Will definitely not change the patch because of this unrelated finding (which 
seems to be self-healing). Documented for Simon at 
https://www.open-mesh.org/issues/469

Regards,
	Sven