[PATCH mpam mpam/snapshot+extras/v6.18-rc1 v2 0/3] fs/resctrl: IOMMU group fixes for tasks interface and cleanup

[PATCH mpam mpam/snapshot+extras/v6.18-rc1 v2 0/3] fs/resctrl: IOMMU group fixes for tasks interface and cleanup

[Zeng Heng]

This fix patch is against the mpam/snapshot+extras/v6.18-rc1 branch at
https://kernel.googlesource.com/pub/scm/linux/kernel/git/morse/linux.git .

The patch series fixes several issues with IOMMU group handling in the
resctrl filesystem.

Changes
=======

Compared with v1:
  - Split patch 2 into separate patches 2 and 3.

Previous Versions
=================

  v1: https://lore.kernel.org/all/20251107063300.1580046-1-zengheng4@huawei.com/

---

Zeng Heng (3):
  fs/resctrl: Fix incorrect PID parsing after IOMMU group token
  fs/resctrl: Remove unused 'of' parameter from rdtgroup_move_iommu()
  fs/resctrl: Migrate IOMMU groups when removing resource groups

 fs/resctrl/rdtgroup.c | 91 ++++++++++++++++++++++++++++++++++---------
 1 file changed, 73 insertions(+), 18 deletions(-)

--
2.25.1

[PATCH mpam mpam/snapshot+extras/v6.18-rc1 v2 1/3] fs/resctrl: Fix incorrect PID parsing after IOMMU group token

[Zeng Heng]

When the tasks interface receives an "iommu_group:id" configuration,
the original code fails to skip the PID parsing logic after processing
the IOMMU group. This causes the same token to be incorrectly passed
to kstrtoint() as a PID, resulting in -EINVAL.

Restructure the conditional logic to use explicit if-else branches,
ensuring that IOMMU group tokens are processed by rdtgroup_move_iommu()
and then skipped.

This fix also enables proper handling of mixed configurations with
multiple consecutive iommu_group:id and pid entries (e.g.,
echo "iommu_group:1,1234,iommu_group:2,5678" > tasks).

Fixes: 98b622c413ee ("fs/resctrl: Add support for assigning iommu_groups to resctrl groups")
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
---
 fs/resctrl/rdtgroup.c | 39 ++++++++++++++++++++++++---------------
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 5381233adceb..1810ace9538f 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -848,24 +848,33 @@ static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of,
 		pid_str = strim(strsep(&buf, ","));
 
 		is_iommu = string_is_iommu_group(pid_str, &iommu_group_id);
-		if (is_iommu)
+		if (is_iommu) {
 			ret = rdtgroup_move_iommu(iommu_group_id, rdtgrp, of);
-		else if (kstrtoint(pid_str, 0, &pid)) {
-			rdt_last_cmd_printf("Task list parsing error pid %s\n", pid_str);
-			ret = -EINVAL;
-			break;
-		}
+			if (ret) {
+				rdt_last_cmd_printf("Error while processing iommu_group %d\n",
+						     iommu_group_id);
+				break;
+			}
+		} else {
+			if (kstrtoint(pid_str, 0, &pid)) {
+				rdt_last_cmd_printf("Task list parsing error pid %s\n",
+						     pid_str);
+				ret = -EINVAL;
+				break;
+			}
 
-		if (pid < 0) {
-			rdt_last_cmd_printf("Invalid pid %d\n", pid);
-			ret = -EINVAL;
-			break;
-		}
+			if (pid < 0) {
+				rdt_last_cmd_printf("Invalid pid %d\n", pid);
+				ret = -EINVAL;
+				break;
+			}
 
-		ret = rdtgroup_move_task(pid, rdtgrp, of);
-		if (ret) {
-			rdt_last_cmd_printf("Error while processing task %d\n", pid);
-			break;
+			ret = rdtgroup_move_task(pid, rdtgrp, of);
+			if (ret) {
+				rdt_last_cmd_printf("Error while processing task %d\n",
+						     pid);
+				break;
+			}
 		}
 	}
 
-- 
2.25.1

[PATCH mpam mpam/snapshot+extras/v6.18-rc1 v2 2/3] fs/resctrl: Remove unused 'of' parameter from rdtgroup_move_iommu()

[Zeng Heng]

The 'of' (kernfs_open_file) parameter in rdtgroup_move_iommu() is
not used within the function body. Remove it to simplify the
interface and eliminate the unnecessary argument passing.

Signed-off-by: Zeng Heng <zengheng4@huawei.com>
---
 fs/resctrl/rdtgroup.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 1810ace9538f..e92b5dcb6f2e 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -767,8 +767,7 @@ static int rdtgroup_move_task(pid_t pid, struct rdtgroup *rdtgrp,
 	return ret;
 }
 
-static int rdtgroup_move_iommu(int iommu_group_id, struct rdtgroup *rdtgrp,
-			       struct kernfs_open_file *of)
+static int rdtgroup_move_iommu(int iommu_group_id, struct rdtgroup *rdtgrp)
 {
 	const struct cred *cred = current_cred();
 	struct iommu_group *iommu_group;
@@ -849,7 +848,7 @@ static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of,
 
 		is_iommu = string_is_iommu_group(pid_str, &iommu_group_id);
 		if (is_iommu) {
-			ret = rdtgroup_move_iommu(iommu_group_id, rdtgrp, of);
+			ret = rdtgroup_move_iommu(iommu_group_id, rdtgrp);
 			if (ret) {
 				rdt_last_cmd_printf("Error while processing iommu_group %d\n",
 						     iommu_group_id);
-- 
2.25.1

[PATCH mpam mpam/snapshot+extras/v6.18-rc1 v2 3/3] fs/resctrl: Migrate IOMMU groups when removing resource groups

[Zeng Heng]

When deleting a control group, monitor group, or unmounting the resctrl
filesystem, migrate all associated IOMMU groups to the appropriate
destination:
  * Control group deletion: move IOMMU groups to the default group
  * Monitor group deletion: move IOMMU groups to the parent control group
  * Filesystem unmount: move all IOMMU groups to the default group

Without this migration, IOMMU groups remain bound to stale PARTID/PMG
values of the destroyed group, causing them to "disappear" from the
resctrl interface.

Add rdt_move_group_iommus() to handle this migration, mirroring the
existing rdt_move_group_tasks() pattern for task migration.

When deleting a control group or unmounting the resctrl file system, it
is necessary to move its all iommu_groups back to the default group. When
removing a monitor group, need to move its iommu_groups back to the parent
control group.

Otherwise, these iommu_groups remain bound to the old PARTID and PMG, and
they will appear to "disappear" from the resctrl fs.

Signed-off-by: Zeng Heng <zengheng4@huawei.com>
---
 fs/resctrl/rdtgroup.c | 47 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index e92b5dcb6f2e..351e430bde1a 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -3292,6 +3292,44 @@ static void rdt_move_group_tasks(struct rdtgroup *from, struct rdtgroup *to,
 	read_unlock(&tasklist_lock);
 }
 
+static int rdt_move_group_iommus(struct rdtgroup *from, struct rdtgroup *to)
+{
+	struct kset *iommu_groups;
+	struct iommu_group *group;
+	int err = 0, iommu_group_id;
+	struct kobject *group_kobj = NULL;
+
+	if (!IS_ENABLED(CONFIG_RESCTRL_IOMMU))
+		return 0;
+
+	if (from == to)
+		return 0;
+
+	iommu_groups = iommu_get_group_kset();
+
+	while ((group_kobj = kset_get_next_obj(iommu_groups, group_kobj))) {
+		/* iommu_group_get_from_kobj() wants to drop a reference */
+		kobject_get(group_kobj);
+
+		group = iommu_group_get_from_kobj(group_kobj);
+		if (!group)
+			continue;
+
+		if (!from || iommu_matches_rdtgroup(group, from)) {
+			err = kstrtoint(group_kobj->name, 0, &iommu_group_id);
+			if (err)
+				break;
+
+			err = rdtgroup_move_iommu(iommu_group_id, to);
+			if (err)
+				break;
+		}
+	}
+
+	kset_put(iommu_groups);
+	return err;
+}
+
 static void free_all_child_rdtgrp(struct rdtgroup *rdtgrp)
 {
 	struct rdtgroup *sentry, *stmp;
@@ -3320,6 +3358,9 @@ static void rmdir_all_sub(void)
 	/* Move all tasks to the default resource group */
 	rdt_move_group_tasks(NULL, &rdtgroup_default, NULL);
 
+	/* Move all iommu_groups to the default resource group */
+	rdt_move_group_iommus(NULL, &rdtgroup_default);
+
 	list_for_each_entry_safe(rdtgrp, tmp, &rdt_all_groups, rdtgroup_list) {
 		/* Free any child rmids */
 		free_all_child_rdtgrp(rdtgrp);
@@ -4189,6 +4230,9 @@ static int rdtgroup_rmdir_mon(struct rdtgroup *rdtgrp, cpumask_var_t tmpmask)
 	/* Give any tasks back to the parent group */
 	rdt_move_group_tasks(rdtgrp, prdtgrp, tmpmask);
 
+	/* Give any iommu_groups back to the parent group */
+	rdt_move_group_iommus(rdtgrp, prdtgrp);
+
 	/*
 	 * Update per cpu closid/rmid of the moved CPUs first.
 	 * Note: the closid will not change, but the arch code still needs it.
@@ -4239,6 +4283,9 @@ static int rdtgroup_rmdir_ctrl(struct rdtgroup *rdtgrp, cpumask_var_t tmpmask)
 	/* Give any tasks back to the default group */
 	rdt_move_group_tasks(rdtgrp, &rdtgroup_default, tmpmask);
 
+	/* Give any iommu_groups back to the default group */
+	rdt_move_group_iommus(rdtgrp, &rdtgroup_default);
+
 	/* Give any CPUs back to the default group */
 	cpumask_or(&rdtgroup_default.cpu_mask,
 		   &rdtgroup_default.cpu_mask, &rdtgrp->cpu_mask);
-- 
2.25.1

Re: [PATCH mpam mpam/snapshot+extras/v6.18-rc1 v2 3/3] fs/resctrl: Migrate IOMMU groups when removing resource groups

[Lee Trager]

Hi Zeng,

Thanks for the series, I found it while backporting MPAM support to 6.18.

On 4/13/26 8:26 PM, Zeng Heng wrote:
> When deleting a control group, monitor group, or unmounting the resctrl
> filesystem, migrate all associated IOMMU groups to the appropriate
> destination:
>    * Control group deletion: move IOMMU groups to the default group
>    * Monitor group deletion: move IOMMU groups to the parent control group
>    * Filesystem unmount: move all IOMMU groups to the default group
>
> Without this migration, IOMMU groups remain bound to stale PARTID/PMG
> values of the destroyed group, causing them to "disappear" from the
> resctrl interface.
>
> Add rdt_move_group_iommus() to handle this migration, mirroring the
> existing rdt_move_group_tasks() pattern for task migration.
>
> When deleting a control group or unmounting the resctrl file system, it
> is necessary to move its all iommu_groups back to the default group. When
> removing a monitor group, need to move its iommu_groups back to the parent
> control group.
>
> Otherwise, these iommu_groups remain bound to the old PARTID and PMG, and
> they will appear to "disappear" from the resctrl fs.
>
> Signed-off-by: Zeng Heng <zengheng4@huawei.com>
> ---
>   fs/resctrl/rdtgroup.c | 47 +++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 47 insertions(+)
>
> diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
> index e92b5dcb6f2e..351e430bde1a 100644
> --- a/fs/resctrl/rdtgroup.c
> +++ b/fs/resctrl/rdtgroup.c
> @@ -3292,6 +3292,44 @@ static void rdt_move_group_tasks(struct rdtgroup *from, struct rdtgroup *to,
>   	read_unlock(&tasklist_lock);
>   }
>   
> +static int rdt_move_group_iommus(struct rdtgroup *from, struct rdtgroup *to)
> +{
> +	struct kset *iommu_groups;
> +	struct iommu_group *group;
> +	int err = 0, iommu_group_id;
> +	struct kobject *group_kobj = NULL;
> +
> +	if (!IS_ENABLED(CONFIG_RESCTRL_IOMMU))
> +		return 0;
> +
> +	if (from == to)
> +		return 0;
> +
> +	iommu_groups = iommu_get_group_kset();
> +
> +	while ((group_kobj = kset_get_next_obj(iommu_groups, group_kobj))) {
> +		/* iommu_group_get_from_kobj() wants to drop a reference */
> +		kobject_get(group_kobj);
> +
> +		group = iommu_group_get_from_kobj(group_kobj);
> +		if (!group)
> +			continue;
> +
> +		if (!from || iommu_matches_rdtgroup(group, from)) {
> +			err = kstrtoint(group_kobj->name, 0, &iommu_group_id);
> +			if (err)
> +				break;
> +
> +			err = rdtgroup_move_iommu(iommu_group_id, to);
> +			if (err)
> +				break;
> +		}
> +	}
> +
> +	kset_put(iommu_groups);
> +	return err;
> +}

iommu_group_get_from_kobj() returns holding a reference on 
group->devices_kobj, the one iommu_group_put() releases. The 
kobject_get() above only compensates for the kobject_put(&group->kobj) 
done internally by iommu_group_get_from_kobj(). Nothing in this loop 
ever calls iommu_group_put(), so this leaks one iommu_group reference  
per group in the kset on every call, e.g on rmdir and every unmount. 
Since device_kobj pins the group's koject, the leaked groups can never 
be freed.

The same pattern exists in show_rdt_iommu() from "fs/resctrl: Add 
support for assigning iommu_groups to resctrl groups", where it leaks 
one reference per group on every read of a tasks file.

There is a second, smaller leak on these break paths: 
kset_get_next_obj() only drops its reference on the current kobject when 
it is passed back as @prev on the next iteration, so breaking out of the 
loop also leaks the group_kobj reference taken by the iterator. I am 
carrying the fix below:

if (!from || iommu_matches_rdtgroup(group, from)) {
	err = kstrtoint(group_kobj->name, 0, &iommu_group_id);
	if (!err)
		err = rdtgroup_move_iommu(iommu_group_id, to);
}

iommu_group_put(group);
if (err) {
	kobject_put(group_kobj);
	break;
}

Thanks,

Lee

Re: [PATCH mpam mpam/snapshot+extras/v6.18-rc1 v2 3/3] fs/resctrl: Migrate IOMMU groups when removing resource groups

[Zeng Heng]

Hi Lee,

On 2026/7/16 5:35, Lee Trager wrote:
> Hi Zeng,
> 
> Thanks for the series, I found it while backporting MPAM support to 6.18.
> 

You are welcome. Glad it could help you fix the issues you encountered.


> iommu_group_get_from_kobj() returns holding a reference on 
> group->devices_kobj, the one iommu_group_put() releases. The 
> kobject_get() above only compensates for the kobject_put(&group->kobj) 
> done internally by iommu_group_get_from_kobj(). Nothing in this loop 
> ever calls iommu_group_put(), so this leaks one iommu_group reference 
> per group in the kset on every call, e.g on rmdir and every unmount. 
> Since device_kobj pins the group's koject, the leaked groups can never 
> be freed.
> 
> The same pattern exists in show_rdt_iommu() from "fs/resctrl: Add 
> support for assigning iommu_groups to resctrl groups", where it leaks 
> one reference per group on every read of a tasks file.
> 
> There is a second, smaller leak on these break paths: 
> kset_get_next_obj() only drops its reference on the current kobject when 
> it is passed back as @prev on the next iteration, so breaking out of the 
> loop also leaks the group_kobj reference taken by the iterator. I am 
> carrying the fix below:
> 
> if (!from || iommu_matches_rdtgroup(group, from)) {
>      err = kstrtoint(group_kobj->name, 0, &iommu_group_id);
>      if (!err)
>          err = rdtgroup_move_iommu(iommu_group_id, to);
> }
> 
> iommu_group_put(group);
> if (err) {
>      kobject_put(group_kobj);
>      break;
> }
> 
> Thanks,
> 

Thank you for the review. The changes look reasonable to me, and I'll
carry these memory leak fixes into v3.


Best regards,
Zeng Heng