[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <91026839-2f2e-4562-aa77-6901148c89ad@intel.com>
Date: Wed, 19 Feb 2025 20:42:28 -0800
From: Reinette Chatre <reinette.chatre@...el.com>
To: James Morse <james.morse@....com>, <x86@...nel.org>,
<linux-kernel@...r.kernel.org>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, H Peter Anvin <hpa@...or.com>, Babu Moger
<Babu.Moger@....com>, <shameerali.kolothum.thodi@...wei.com>, "D Scott
Phillips OS" <scott@...amperecomputing.com>, <carl@...amperecomputing.com>,
<lcherian@...vell.com>, <bobo.shaobowang@...wei.com>,
<tan.shaopeng@...itsu.com>, <baolin.wang@...ux.alibaba.com>, Jamie Iles
<quic_jiles@...cinc.com>, Xin Hao <xhao@...ux.alibaba.com>,
<peternewman@...gle.com>, <dfustini@...libre.com>, <amitsinght@...vell.com>,
David Hildenbrand <david@...hat.com>, Rex Nie <rex.nie@...uarmicro.com>,
"Dave Martin" <dave.martin@....com>, Koba Ko <kobak@...dia.com>, Shanker
Donthineni <sdonthineni@...dia.com>, Shaopeng Tan
<tan.shaopeng@...fujitsu.com>, "Tony Luck" <tony.luck@...el.com>
Subject: Re: [PATCH v6 33/42] x86/resctrl: resctrl_exit() teardown resctrl but
leave the mount point
Hi James,
On 2/7/25 10:18 AM, James Morse wrote:
> resctrl_exit() was intended for use when the 'resctrl' module was unloaded.
> resctrl can't be built as a module, and the kernfs helpers are not exported
> so this is unlikely to change. MPAM has an error interrupt which indicates
> the MPAM driver has gone haywire. Should this occur tasks could run with
> the wrong control values, leading to bad performance for important tasks.
> The MPAM driver needs a way to tell resctrl that no further configuration
> should be attempted.
>
> Using resctrl_exit() for this leaves the system in a funny state as
> resctrl is still mounted, but cannot be un-mounted because the sysfs
> directory that is typically used has been removed. Dave Martin suggests
> this may cause systemd trouble in the future as not all filesystems
> can be unmounted.
>
> Add calls to remove all the files and directories in resctrl, and
> remove the sysfs_remove_mount_point() call that leaves the system
> in a funny state. When triggered, this causes all the resctrl files
> to disappear. resctrl can be unmounted, but not mounted again.
>
> Signed-off-by: James Morse <james.morse@....com>
> Tested-by: Carl Worth <carl@...amperecomputing.com> # arm64
> Tested-by: Shaopeng Tan <tan.shaopeng@...fujitsu.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@...fujitsu.com>
> Reviewed-by: Tony Luck <tony.luck@...el.com>
> ---
> Changes since v5:
> * Serialise rdtgroup_destroy_root() against umount().
> * Check rdtgroup_default.kn to protect against duplicate calls.
> ---
> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 6e30283358d4..424622d2f959 100644
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@ -4092,8 +4092,12 @@ static int rdtgroup_setup_root(struct rdt_fs_context *ctx)
>
> static void rdtgroup_destroy_root(void)
> {
> - kernfs_destroy_root(rdt_root);
> - rdtgroup_default.kn = NULL;
> + lockdep_assert_held(&rdtgroup_mutex);
> +
> + if (rdtgroup_default.kn) {
> + kernfs_destroy_root(rdt_root);
> + rdtgroup_default.kn = NULL;
> + }
> }
>
> static void __init rdtgroup_setup_default(void)
> @@ -4371,9 +4375,12 @@ int __init resctrl_init(void)
>
Could you please add the kerneldoc you proposed in
https://lore.kernel.org/lkml/f2ecb501-bc65-49a9-903d-80ba1737845f@arm.com/ ?
> void __exit resctrl_exit(void)
> {
> + mutex_lock(&rdtgroup_mutex);
> + rdtgroup_destroy_root();
> + mutex_unlock(&rdtgroup_mutex);
> +
> debugfs_remove_recursive(debugfs_resctrl);
> unregister_filesystem(&rdt_fs_type);
> - sysfs_remove_mount_point(fs_kobj, "resctrl");
>
> resctrl_mon_resource_exit();
> }
It is difficult for me to follow the kernfs reference counting required
to make this work. Specifically, the root kn is "destroyed" here but it
is required to stick around until unmount when the rest of the files
are removed. Have you been able to test this flow? I think you mentioned
something like this before but I cannot find the details now.
Reinette
Powered by blists - more mailing lists