Actions
Bug #477
opentt: fix handling of __batadv_tt_local_event() allocation errors
Start date:
10/02/2026
Due date:
% Done:
0%
Estimated time:
Description
> [Severity: Medium]
> This isn't a bug introduced by this patch, but what happens if the
> change node allocation fails here? batadv_tt_local_event() returns
> silently:
>
> tt_change_node = kmem_cache_alloc(batadv_tt_change_cache, GFP_ATOMIC);
> if (!tt_change_node)
> return;
>
> By then batadv_tt_local_mark_removed() has already set
> BATADV_TT_CLIENT_PENDING and will return true, so
> batadv_tt_local_remove() skips the immediate removal. No DEL is queued
> and local_changes isn't incremented. The void return leaves no way to
> undo PENDING.
>
> If another change makes local_changes non-zero, the next commit's
> batadv_tt_local_purge_pending_clients() drops the entry from the table
> and the CRC. No DEL is ever announced.
>
> If there are no other changes, batadv_tt_local_commit_changes_nolock()
> returns early:
>
> if (READ_ONCE(bat_priv->tt.local_changes) == 0) {
> ...
> return;
> }
>
> batadv_tt_local_purge_list() also skips entries that are already
> PENDING. The removal is never retried, and neighbours keep stale client
> information.
>
> The same order is still there at the end of the series.
> batadv_tt_local_set_pending() calls __batadv_tt_local_event() and then
> sets PENDING unconditionally.
Updated by Sven Eckelmann 5 days ago
from my reply:
If another change makes local_changes non-zero, the next commit's
batadv_tt_local_purge_pending_clients() drops the entry from the table
and the CRC. No DEL is ever announced.The not announced DEL seems to be OK for me here. Of course, in an ideal world, we would have infinite RAM and never have allocation errors. But falling back to a full sync is a viable option.
The only thing I don't like is the delayed recalculation of the CRC on an allocation error. And this is caused by the precheck in
batadv_tt_local_commit_changes_nolockwhich depends onlocal_changesinstead of a flag which announces any potential change (even when the allocation for the changes announcement list failed).
Actions