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

[Josh Law <objecting@objecting.org>]

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