linux-kernel - Re: [PATCH v8 1/8] x86/resctrl: Add multiple tasks to the resctrl group at once

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <a59be218-350b-b88b-2b02-be9c1d2bf797@intel.com>
Date:   Fri, 1 Sep 2023 15:13:40 -0700
From:   Fenghua Yu <fenghua.yu@...el.com>
To:     Babu Moger <babu.moger@....com>, <corbet@....net>,
        <reinette.chatre@...el.com>, <tglx@...utronix.de>,
        <mingo@...hat.com>, <bp@...en8.de>
CC:     <dave.hansen@...ux.intel.com>, <x86@...nel.org>, <hpa@...or.com>,
        <paulmck@...nel.org>, <akpm@...ux-foundation.org>,
        <quic_neeraju@...cinc.com>, <rdunlap@...radead.org>,
        <damien.lemoal@...nsource.wdc.com>, <songmuchun@...edance.com>,
        <peterz@...radead.org>, <jpoimboe@...nel.org>,
        <pbonzini@...hat.com>, <chang.seok.bae@...el.com>,
        <pawan.kumar.gupta@...ux.intel.com>, <jmattson@...gle.com>,
        <daniel.sneddon@...ux.intel.com>, <sandipan.das@....com>,
        <tony.luck@...el.com>, <james.morse@....com>,
        <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <bagasdotme@...il.com>, <eranian@...gle.com>,
        <christophe.leroy@...roup.eu>, <jarkko@...nel.org>,
        <adrian.hunter@...el.com>, <quic_jiles@...cinc.com>,
        <peternewman@...gle.com>
Subject: Re: [PATCH v8 1/8] x86/resctrl: Add multiple tasks to the resctrl
 group at once

Hi, Babu,

On 8/21/23 16:30, Babu Moger wrote:
> The resctrl task assignment for monitor or control group needs to be
> done one at a time. For example:
> 
>    $mount -t resctrl resctrl /sys/fs/resctrl/
>    $mkdir /sys/fs/resctrl/ctrl_grp1
>    $echo 123 > /sys/fs/resctrl/ctrl_grp1/tasks
>    $echo 456 > /sys/fs/resctrl/ctrl_grp1/tasks
>    $echo 789 > /sys/fs/resctrl/ctrl_grp1/tasks
> 
> This is not user-friendly when dealing with hundreds of tasks.
> 
> Support multiple task assignment in one command with tasks ids separated
> by commas. For example:
>    $echo 123,456,789 > /sys/fs/resctrl/ctrl_grp1/tasks
> 
> Reviewed-by: Tan Shaopeng <tan.shaopeng@...fujitsu.com>
> Tested-by: Tan Shaopeng <tan.shaopeng@...fujitsu.com>
> Signed-off-by: Babu Moger <babu.moger@....com>
> Reviewed-by: Reinette Chatre <reinette.chatre@...el.com>
> ---
>   Documentation/arch/x86/resctrl.rst     |  8 +++++++-
>   arch/x86/kernel/cpu/resctrl/rdtgroup.c | 25 ++++++++++++++++++++++---
>   2 files changed, 29 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/arch/x86/resctrl.rst b/Documentation/arch/x86/resctrl.rst
> index cb05d90111b4..af234681756e 100644
> --- a/Documentation/arch/x86/resctrl.rst
> +++ b/Documentation/arch/x86/resctrl.rst
> @@ -299,7 +299,13 @@ All groups contain the following files:
>   "tasks":
>   	Reading this file shows the list of all tasks that belong to
>   	this group. Writing a task id to the file will add a task to the
> -	group. If the group is a CTRL_MON group the task is removed from
> +	group. Multiple tasks can be added by separating the task ids
> +	with commas. Tasks will be assigned sequentially. Multiple
> +	failures are not supported. A single failure encountered while
> +	attempting to assign a task will cause the operation to abort.

What happens to the already moved tasks when "abort"?

Could you please add add more details on "abort"?

"A single failure encountered while attempting to assign a task will 
cause the operation to abort and already added tasks before the failure 
will remain in the group."

> +	Failures will be logged to /sys/fs/resctrl/info/last_cmd_status.
> +
> +	If the group is a CTRL_MON group the task is removed from
>   	whichever previous CTRL_MON group owned the task and also from
>   	any MON group that owned the task. If the group is a MON group,
>   	then the task must already belong to the CTRL_MON parent of this
> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 725344048f85..8c91c333f9b3 100644
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@ -696,11 +696,10 @@ static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of,
>   				    char *buf, size_t nbytes, loff_t off)
>   {
>   	struct rdtgroup *rdtgrp;
> +	char *pid_str;
>   	int ret = 0;
>   	pid_t pid;
>   
> -	if (kstrtoint(strstrip(buf), 0, &pid) || pid < 0)
> -		return -EINVAL;
>   	rdtgrp = rdtgroup_kn_lock_live(of->kn);
>   	if (!rdtgrp) {
>   		rdtgroup_kn_unlock(of->kn);
> @@ -715,7 +714,27 @@ static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of,
>   		goto unlock;
>   	}
>   
> -	ret = rdtgroup_move_task(pid, rdtgrp, of);
> +	while (buf && buf[0] != '\0' && buf[0] != '\n') {
> +		pid_str = strim(strsep(&buf, ","));
> +
> +		if (kstrtoint(pid_str, 0, &pid)) {
> +			rdt_last_cmd_puts("Task list parsing error\n");

It would be better to show the failed pid string in the failure report:
+			rdt_last_cmd_puts("Task list parsing error pid %s\n", pid_str);

So user will know which pid string causes the failure?

> +			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;
> +		}
> +	}
>   
>   unlock:
>   	rdtgroup_kn_unlock(of->kn);

Thanks.

-Fenghua