Re: [PATCH v9 25/31] fs/resctrl: Move allocation/free of closid_num_dirty_rmid

["Luck, Tony" <tony.luck@intel.com>]

On Thu, Sep 11, 2025 at 03:26:44PM -0700, Luck, Tony wrote:
> James,
> 
> While refactoring code, I missed moving the mutex_lock(&rdtgroup_mutex);
> that was protecting the allocation of "closid_num_dirty_rmid[]" ... and
> Reinette caught this change.
> 
> But looking at the code, I'm not at all sure what protection is needed
> for the allocation/free of this array. The current calling sequence for
> allocation is:
> 
> Linux late_init
>     resctrl_arch_late_init()
> 	resctrl_init()
> 	    resctrl_l3_mon_resource_init
> 		 dom_data_init()
> 
> which doesn't appear to provide any scope for other CPUs to come in and
> start using closid_num_dirty_rmid[]
> 
> The free path also seems safe too, as all resctrl functions should
> be shutdown before calling:
> 
> resctrl_arch_exit()
>     resctrl_exit()
> 	resctrl_l3_mon_resource_exit()
> 	    dom_data_exit()
> 
> and if they were not, holding the rdtgroup_mutex around:
> 
> 	kfree(closid_num_dirty_rmid);
> 	closid_num_dirty_rmid = NULL;
> 
> would do nothing to prevent some still active resctrl function
> from tripping over a NULL pointer.
> 
> 
> So, unless I'm missing something, I'm planning to address Reinette's
> find by documenting inmy commit message that holding rdtgroup_mutex
> has always been unnecessary, so it is dropped as part of this refactor.

James,

Cancel this request. Reinette pointed me at the discussions last year
about allocation[1] and free[2] where you descibed how memory ordering on
ARM might be a concern and the mutex makes it obvious that the access to
closid_num_dirty_rmid is safe.

-Tony

[1] https://lore.kernel.org/lkml/20b566d9-448b-5367-b4db-593466e7a2f8@arm.com/
[2] https://lore.kernel.org/lkml/52f81c45-efa7-42c7-86f4-fc1084b1d57a@redhat.com/