Re: [PATCH v2 1/4] mm, swap: Fix potential NULL dereference when trying a sleep table allocation

[Kemeng Shi]

在 2026/8/29 9:03:38, Andrew Morton 写道:
> On Thu, 27 Aug 2026 17:10:54 +0800 Kairui Song <ryncsn@xxxxxxxxx> wrote:
> 
>>> --- a/mm/swapfile.c
>>> +++ b/mm/swapfile.c
>>> @@ -466,8 +466,6 @@ static int swap_cluster_alloc_table(struct swap_cluster_info *ci, gfp_t gfp)
>>>  	if (!table)
>>>  		return -ENOMEM;
>>>  
>>> -	rcu_assign_pointer(ci->table, table);
>>> -
>>>  #ifdef CONFIG_MEMCG
>>>  	if (!mem_cgroup_disabled()) {
>>>  		VM_WARN_ON_ONCE(ci->memcg_table);
>>> @@ -487,6 +485,12 @@ static int swap_cluster_alloc_table(struct swap_cluster_info *ci, gfp_t gfp)
>>>  		return -ENOMEM;
>>>  	}
>>>  #endif
>>> +
>>> +	/*
>>> +	 * Make tables visible to cluster_is_usable() after everything is
>>> +	 * ready.
>>> +	 */
>>> +	rcu_assign_pointer(ci->table, table);
>>
>> Hmm, but for the error paths above, they will leak the new allocated table?
> 
> Sashiko thinks so ;)
> 
> It also might have found a pre-existing data-race which seems
> sufficiently on-topic for this patchset?
> 
> 	https://sashiko.dev/#/patchset/20260820115505.20027-1-shikemeng@xxxxxxxxxxxxxxx
Thanks for thre review, I will address the leak in the next version.

As for data-race concern, I analyzed it in [1] and concluded that the cluster lock
already serializes all accesses in question:

/* ci->table: protected by cluster lock */
swap_cluster_lock()
cluster_is_usable()
 cluster_table_is_alloced()
swap_cluster_unlock()

/* memcg_table: protected by cluster lock */
mem_cgroup_try_charge_swap
 swap_cluster_get_and_lock()
 __swap_cgroup_set()
 swap_cluster_unlock()

/* zero_bitmap: protected by cluster lock */
swap_writeout
 swap_zeromap_folio_set
  swap_cluster_get_and_lock
  __swap_table_set_zero
  swap_cluster_unlock

Since all three accessors acquire the same cluster lock, no data race
or memory-ordering issue exists on these shared variables.

Please let me know if I miss any case.

[1] https://lore.kernel.org/all/76738b02-1f12-4deb-84f7-542d9830b0b5@xxxxxxxxxxxxxxx/

Thanks,
Kemeng