Re: [PATCH] lib/assoc_array: fix stale nr_leaves_on_tree after gc

Josh Law
2026-03-18T17:29:16Z

On 18 March 2026 17:23:19 GMT, Andrew Morton <akpm@linux-foundation.org> wrote:
>On Wed, 18 Mar 2026 16:49:59 +0000 Josh Law <objecting@objecting.org> wrote:
>
>> In assoc_array_gc(), assoc_array_apply_edit() publishes the new tree
>> root before nr_leaves_on_tree is updated, creating a window where the
>> tree is visible with a stale leaf count. Move the nr_leaves_on_tree
>> assignment before assoc_array_apply_edit() so the count is consistent
>> when the new root becomes visible.
>>
>> ...
>>
>> --- a/lib/assoc_array.c
>> +++ b/lib/assoc_array.c
>> @@ -1711,8 +1711,8 @@ int assoc_array_gc(struct assoc_array *array,
>>
>> gc_complete:
>> edit->set[0].to = new_root;
>> - assoc_array_apply_edit(edit);
>> array->nr_leaves_on_tree = nr_leaves_on_tree;
>> + assoc_array_apply_edit(edit);
>> return 0;
>
>But assoc_array_apply_edit() alters array->nr_leaves_on_tree and now we
>immediately overwrite that alteration?

Hi Andrew,

It probably doesn't overwrite it in this specific case.

In assoc_array_gc(), the edit script is zero-initialized, meaning edit->adjust_count_on is NULL. Because of this (and since array->root isn't NULL), assoc_array_apply_edit() safely skips the block that modifies nr_leaves_on_tree.

Since apply_edit() doesn't touch the count here, the explicit assignment right after is necessary to record the newly calculated post-GC count.

V/R

Josh Law