Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <678ab8b6-9465-cdeb-da65-448c0cf075f5@intel.com>
Date:   Tue, 18 Apr 2023 14:52:51 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.10.0
Subject: Re: [PATCH v5 2/3] x86/resctrl: Implement rename op for mon groups
Content-Language: en-US
To:     Peter Newman <peternewman@google.com>, <fenghua.yu@intel.com>
CC:     <Babu.Moger@amd.com>, <bp@alien8.de>,
        <dave.hansen@linux.intel.com>, <eranian@google.com>,
        <gupasani@google.com>, <hpa@zytor.com>, <james.morse@arm.com>,
        <linux-kernel@vger.kernel.org>, <mingo@redhat.com>,
        <skodak@google.com>, <tglx@linutronix.de>, <tony.luck@intel.com>,
        <x86@kernel.org>
References: <20230330135558.1019658-1-peternewman@google.com>
 <20230330135558.1019658-3-peternewman@google.com>
From:   Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <20230330135558.1019658-3-peternewman@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?d3ZSU1g5ZWdEc2tNbXNFS1NaejN6U05iKzBqMEpPaDlmSVM5RFNCNjM3ZXpM?=
 =?utf-8?B?UFFUYlE2bWp5NWVoZVBsM1lnZENZTGxLVmdTL3dSZDN4d3JOWDR6MFNWaGFv?=
 =?utf-8?B?MmlBYkFZMkpaOUhOcTRtK3hkaE9QcEVtWjd1eDl5RXlBRFdYRG9IS3lEZDJy?=
 =?utf-8?B?QmR3ZU5TUDUreDJXT0xoQkdJNU8yMUJhVmhkQW5LLzV4dHRzNmw3Kyt3dU0w?=
 =?utf-8?B?MzF3S203Q1ZzVUxZZ1Y0eHk3UkcrRVg3WWYxVkRpd0Z0Q1QzS2pJbkhSb2ZD?=
 =?utf-8?B?L0RxTlRsMG1lVjFHMjV3UHVXMjRQSTVDQURUS0N4OVFEak9rWUlDUGJ3Vnk0?=
 =?utf-8?B?cERyVEFhQjdET2RBSGFlQy9PN2ErUlovNkE0ck5tdFhzZnF1WEV1N1hzRDM0?=
 =?utf-8?B?V0d4WFJ6UGJ0anowTm04K25tUjZDY2gwbk5NV0hkYThvS1BKOEQ2QmEyM2FH?=
 =?utf-8?B?ZkJoVkU4aVNmOTJPRlphYWVFUUxjL21UWXYwZVRmVHVWd1RWSHNRdzQvODl0?=
 =?utf-8?B?bVZnL2Q3MEdJNjVBZmJ2NEVqOTBrOUY3aHNNeXhXbkdzSWRHeDhWdDR6Nmhk?=
 =?utf-8?B?bzJSdlU0VytzMnIvRFVFc1VEVlNwaElidDA3L0pLSXd1TWZHNHgzREZ6b2No?=
 =?utf-8?B?TkM1UnV4ME4xODE0TEQzNlFXY0k4elFHcjY2UUUxM1Q4SnJOcnVjKzhpRTF4?=
 =?utf-8?B?cHQ5K3hQd1lyYk5YV0JsNUU0cXZEUitVR3ZuT3hjaW5OVEZqSW1kekhmK2ZH?=
 =?utf-8?B?SmVqZE5rQjBKckF1c1JOZko0bUxGZ1hxSUgrUVBlRjRJdE5hc1dxVlBJc3FF?=
 =?utf-8?B?eWF1WXJjOWh2MkFhbnhBRms0dk5hcWE3Q0VSeWVBLzBETkZ1ckFwd01hcVdB?=
 =?utf-8?B?MDd4OXJIY1FPUUpCdGp4MFRUKzExejdlMFdxQm52Vm9qUzM5dm1MK3dXVUg3?=
 =?utf-8?B?V0FPQnp2dlo1eE1DVU95Nnh3eGZ2OTV0cUtQRCtveEhEY2JyemhzaVN2ZTNV?=
 =?utf-8?B?SStkNnNsZTlSbDJLR3F5TDlTZzhOdjNFWVU0SjMzR2ZjcVB3cDg2b2dCazUw?=
 =?utf-8?B?b2lCVUtPNm1CVUxnUjJIVXV0RHlnOGxkUm5JMzVpanBXUlExWXYzWEdjMnZN?=
 =?utf-8?B?eTZQcE85cjR6cU9TNWt3STNtVEwyOWtBU1ljNDJIL1h4QzlkcXRTdmhUY0Zu?=
 =?utf-8?B?UkR0bHM2bmhHRU43SEc1eEVDa2NvMVp2Zk0rM1Y5MGw0QVZCVDdyWjljRVI1?=
 =?utf-8?B?ZkpLMm04M0RQL29XeWdzK3NPa0gwbVkySEpzR0lRdDNBZy8xUjc1bGlwVTd6?=
 =?utf-8?B?eEV3N3Q1RzlGdFN2K1RVRndrNSt3dTUzVlZtdEhsMFNtSlphWDZWMktkc2JK?=
 =?utf-8?B?cDUzb1lDazJpV0piRmk1V0ZQNFl6N3RSTEJyNUIxMi9xL3RnOXpybE5pY0RY?=
 =?utf-8?B?Wk53aWNRVzZTQy8yUGxLQUJmVS9vQ2NqUTEyTm5MMTJHNUptU1lmc3lXeSsv?=
 =?utf-8?B?dkpqMllsUGZSNFo1ZlRrVC9xSnloL2RmYjRUeHVkc3RGTG14Q2JERlN0UlRS?=
 =?utf-8?B?cEw4bkpUZ3NSa1NGYWt6TmlaWlBGUVI3dVo0UFZlREdqZVF4YTJSWlhrOHpr?=
 =?utf-8?B?b3J2WWhtOTZPTUhpZ0ZYaXNEc0VCblo0WkVsQXdCdlR2MVAxYk1JRE1uQnJx?=
 =?utf-8?B?cThRMTBiQnNYTEl0a2ROV3NVSlhId1ZucTFjaXU4cmNVbHFvc1NxRml0NDBD?=
 =?utf-8?B?ZllDbDlSUGJacllpcXlnOXlCeDVmWExnZW9UNU5nREFkZW11TG5sMFNmY2NB?=
 =?utf-8?B?VXE1NjBtOXhxaDhJKzBkdk5ITnkzWE5hV1NVYlZMVmNLNGNsRFBSNWFOR0dy?=
 =?utf-8?B?cUhGbzBuUUxUVnpDTGV5VlJlNkQzVVRoMXVyMlVWWSs5eGxsbDNNS3cvN3J2?=
 =?utf-8?B?WFl0YkRUTUhpRnhqenpoWEkrZUNqWE95ZWo2bzZBbFp1cDFONDZHMjFvYllr?=
 =?utf-8?B?MHQrYTNmTURwQ0RXWEdLY0t6WXFZbEhoR2NYT3JtVlBiNEo5emdqRWxackxw?=
 =?utf-8?B?NE0rUFZSclVMZnhtckxQSUtCL1lDMC8rSWlVVFk4VktTK0prU0NEYUlsZERE?=
 =?utf-8?B?V2hGaHFURFQrWWRPdE5hbFZhSGcvZTNlQzFINW4rdFQ2SERnK1Y0Z1hEU1Yr?=
 =?utf-8?B?a0E9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a8463cb-b9da-4fe5-a899-08db40574362
X-MS-Exchange-CrossTenant-AuthSource: CY4PR11MB1862.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2023 21:52:54.4017
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ph5qPqBJY+ZwFnVeeIDgCReM+NiTuUCkcbhxz/aabGlPBtKkks4i/64cnNcqjdIQzBjsWr4kKxnL1sETgLhDtZb9Q//YmwZHJrG4v1ORAx8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4742
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,
        URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Peter,

On 3/30/2023 6:55 AM, Peter Newman wrote:
> To change the resources allocated to a large group of tasks, such as an
> application container, a container manager must write all of the tasks'
> IDs into the tasks file interface of the new control group.
> 
> If a container manager is additionally tracking containers' bandwidth
> usage by placing tasks from each into their own monitoring group, it

The above sentence seems to be missing something after the "for each".
It seems to still parse if "for each" is removed.

> must first move the tasks to the default monitoring group of the new
> control group before it can move the tasks into their new monitoring
> groups. This is undesirable because it makes bandwidth usage during the
> move unattributable to the correct tasks and resets monitoring event
> counters and cache usage information for the group.
> 
> Implement the rename operation only for resctrlfs monitor groups to
> enable users to move a monitoring group from one control group to
> another. This effects a change in resources allocated to all the tasks
> in the monitoring group while otherwise leaving the monitoring data
> intact.
> 
> Signed-off-by: Peter Newman <peternewman@google.com>
> ---
>  arch/x86/kernel/cpu/resctrl/rdtgroup.c | 128 +++++++++++++++++++++++++
>  1 file changed, 128 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 51b869149e76..86de22d8e23a 100644
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@ -3514,6 +3514,133 @@ static int rdtgroup_rmdir(struct kernfs_node *kn)
>  	return ret;
>  }
>  
> +/**
> + * mongrp_reparent() - replace parent CTRL_MON group of a MON group
> + * @rdtgrp:		the MON group whose parent should be replaced
> + * @new_prdtgrp:	replacement parent CTRL_MON group for @rdtgrp
> + * @cpus:		cpumask provided by the caller for use during this call
> + *
> + * Replaces the parent CTRL_MON group for a MON group, resulting in all member
> + * tasks' CLOSID immediately changing to that of the new parent group.
> + * Monitoring data for the group is unaffected by this operation.
> + */
> +static void mongrp_reparent(struct rdtgroup *rdtgrp,
> +			    struct rdtgroup *new_prdtgrp,
> +			    cpumask_var_t cpus)
> +{
> +	struct rdtgroup *prdtgrp = rdtgrp->mon.parent;
> +
> +	WARN_ON(rdtgrp->type != RDTMON_GROUP);
> +	WARN_ON(new_prdtgrp->type != RDTCTRL_GROUP);
> +
> +	/* Nothing to do when simply renaming a MON group. */
> +	if (prdtgrp == new_prdtgrp)
> +		return;
> +
> +	WARN_ON(list_empty(&prdtgrp->mon.crdtgrp_list));
> +	list_move_tail(&rdtgrp->mon.crdtgrp_list,
> +		       &new_prdtgrp->mon.crdtgrp_list);
> +
> +	rdtgrp->mon.parent = new_prdtgrp;
> +	rdtgrp->closid = new_prdtgrp->closid;
> +
> +	/* Propagate updated closid to all tasks in this group. */
> +	rdt_move_group_tasks(rdtgrp, rdtgrp, cpus);
> +
> +	update_closid_rmid(cpus, NULL);
> +}
> +
> +static int rdtgroup_rename(struct kernfs_node *kn,
> +			   struct kernfs_node *new_parent, const char *new_name)
> +{
> +	struct rdtgroup *new_prdtgrp;
> +	struct rdtgroup *rdtgrp;
> +	cpumask_var_t tmpmask;
> +	int ret;
> +
> +	rdtgrp = kernfs_to_rdtgroup(kn);
> +	new_prdtgrp = kernfs_to_rdtgroup(new_parent);
> +	if (!rdtgrp || !new_prdtgrp)
> +		return -ENOENT;
> +
> +	/* Release both kernfs active_refs before obtaining rdtgroup mutex. */
> +	rdtgroup_kn_get(rdtgrp, kn);
> +	rdtgroup_kn_get(new_prdtgrp, new_parent);
> +
> +	mutex_lock(&rdtgroup_mutex);
> +
> +	rdt_last_cmd_clear();
> +
> +	/*
> +	 * Don't allow kernfs_to_rdtgroup() to return a parent rdtgroup if
> +	 * either kernfs_node is a file.
> +	 */
> +	if (kernfs_type(kn) != KERNFS_DIR ||
> +	    kernfs_type(new_parent) != KERNFS_DIR) {
> +		rdt_last_cmd_puts("Source and destination must be group directories");

I do not think it is obvious what a "group directory" is. The source must be a
monitoring group and the destination must be the "mon_groups" directory. Maybe
the "group" term can just be dropped to read "Source and destination must be
directories" (which is exactly what is tested for).

> +		ret = -EPERM;
> +		goto out;
> +	}
> +
> +	if ((rdtgrp->flags & RDT_DELETED) || (new_prdtgrp->flags & RDT_DELETED)) {
> +		ret = -ENOENT;
> +		goto out;
> +	}
> +
> +	if (rdtgrp->type != RDTMON_GROUP || !kn->parent ||
> +	    !is_mon_groups(kn->parent, kn->name)) {
> +		rdt_last_cmd_puts("Source must be a MON group\n");
> +		ret = -EPERM;
> +		goto out;
> +	}
> +
> +	if (!is_mon_groups(new_parent, new_name)) {
> +		rdt_last_cmd_puts("Destination must be a mon_groups subdirectory\n");
> +		ret = -EPERM;
> +		goto out;
> +	}
> +

Thanks. I think using these terms ("MON" and "mon_groups") in the error messages
are useful since it gives the user something to search for in the documentation.

> +	/*
> +	 * If the MON group is monitoring CPUs, the CPUs must be assigned to the
> +	 * current parent CTRL_MON group and therefore cannot be assigned to
> +	 * the new parent, making the move illegal.
> +	 */
> +	if (!cpumask_empty(&rdtgrp->cpu_mask) &&
> +	    (rdtgrp->mon.parent != new_prdtgrp)) {

You can remove the extra parentheses so that this patch can get a clean slate
from "checkpatch.pl --strict" done as this work moves to the next level.

> +		rdt_last_cmd_puts("Cannot move a MON group that monitors CPUs\n");
> +		ret = -EPERM;
> +		goto out;
> +	}
> +
> +	/*
> +	 * Allocate the cpumask for use in mongrp_reparent() to avoid the
> +	 * possibility of failing to allocate it after kernfs_rename() has
> +	 * succeeded.
> +	 */
> +	if (!zalloc_cpumask_var(&tmpmask, GFP_KERNEL)) {
> +		ret = -ENOMEM;
> +		goto out;
> +	}
> +
> +	/*
> +	 * Perform all input validation and allocations needed to ensure
> +	 * mongrp_reparent() will succeed before calling kernfs_rename(),
> +	 * otherwise it would be necessary to revert this call if
> +	 * mongrp_reparent() failed.
> +	 */
> +	ret = kernfs_rename(kn, new_parent, new_name);
> +	if (!ret)
> +		mongrp_reparent(rdtgrp, new_prdtgrp, tmpmask);
> +
> +	free_cpumask_var(tmpmask);
> +
> +out:
> +	mutex_unlock(&rdtgroup_mutex);
> +	rdtgroup_kn_put(rdtgrp, kn);
> +	rdtgroup_kn_put(new_prdtgrp, new_parent);
> +	return ret;
> +}
> +
>  static int rdtgroup_show_options(struct seq_file *seq, struct kernfs_root *kf)
>  {
>  	if (resctrl_arch_get_cdp_enabled(RDT_RESOURCE_L3))
> @@ -3531,6 +3658,7 @@ static int rdtgroup_show_options(struct seq_file *seq, struct kernfs_root *kf)
>  static struct kernfs_syscall_ops rdtgroup_kf_syscall_ops = {
>  	.mkdir		= rdtgroup_mkdir,
>  	.rmdir		= rdtgroup_rmdir,
> +	.rename		= rdtgroup_rename,
>  	.show_options	= rdtgroup_show_options,
>  };
>  

Thank you very much.

Just the few minor comments. With those addressed:

Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>

Reinette