linux-kernel - Re: [PATCH v9 25/31] fs/resctrl: Move allocation/free of closid_num_dirty

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aMRWO0u7OKhX-g_6@agluck-desk3>
Date: Fri, 12 Sep 2025 10:19:55 -0700
From: "Luck, Tony" <tony.luck@...el.com>
To: Reinette Chatre <reinette.chatre@...el.com>, James Morse
	<james.morse@....com>
CC: Fenghua Yu <fenghuay@...dia.com>, Maciej Wieczor-Retman
	<maciej.wieczor-retman@...el.com>, Peter Newman <peternewman@...gle.com>,
	Babu Moger <babu.moger@....com>, Drew Fustini <dfustini@...libre.com>, "Dave
 Martin" <Dave.Martin@....com>, Chen Yu <yu.c.chen@...el.com>,
	<x86@...nel.org>, <linux-kernel@...r.kernel.org>, <patches@...ts.linux.dev>
Subject: Re: [PATCH v9 25/31] fs/resctrl: Move allocation/free of
 closid_num_dirty_rmid

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/