Open-Mesh » batman-adv

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

Discovered by: gpt-5-6-sol, opus-5 · Missed by: sashiko-gemini
This is a pre-existing inconsistency rather than something this patch
introduces, but now that the compare and the swap of claim->backbone_gw
both happen under claim->backbone_lock here, should the two remaining
readers be annotated too?

net/batman-adv/bridge_loop_avoidance.c:batadv_bla_del_backbone_claims() {
>     ...
>         hlist_for_each_entry_safe(claim, node_tmp,
>                       head, hash_entry) {
>             if (claim->backbone_gw != backbone_gw)
>                 continue;
>     ...
> }

net/batman-adv/bridge_loop_avoidance.c:batadv_bla_answer_request() {
>     ...
>             /* only own claims are interesting */
>             if (claim->backbone_gw != backbone_gw)
>                 continue;
>     ...
> }

Both do a plain load, not even READ_ONCE(), while types.h documents the
field as:

    /** @backbone_lock: lock protecting backbone_gw pointer */
>     spinlock_t backbone_lock;

At both sites the pointer is only compared and never dereferenced, and in
batadv_bla_del_backbone_claims() a stale comparison still keeps the CRC
parity correct because the deferred batadv_claim_release() XORs the address
out of whichever backbone the claim points at. So this looks like a
KCSAN-visible plain-access race with no functional fallout, but would a
READ_ONCE() or a comment on those two readers be worth adding so the
documented locking rule matches the code?

There are more complains about the locking in batadv_bla_del_backbone_claims. https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260821094813.201800-1-sw%40simonwunderlich.de?part=3