From: Reinette Chatre <reinette.chatre@intel.com>
To: <babu.moger@amd.com>, <corbet@lwn.net>, <fenghua.yu@intel.com>,
<tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de>,
<dave.hansen@linux.intel.com>
Cc: <x86@kernel.org>, <hpa@zytor.com>, <paulmck@kernel.org>,
<rdunlap@infradead.org>, <tj@kernel.org>, <peterz@infradead.org>,
<yanjiewtw@gmail.com>, <kim.phillips@amd.com>,
<lukas.bulwahn@gmail.com>, <seanjc@google.com>,
<jmattson@google.com>, <leitao@debian.org>, <jpoimboe@kernel.org>,
<rick.p.edgecombe@intel.com>, <kirill.shutemov@linux.intel.com>,
<jithu.joseph@intel.com>, <kai.huang@intel.com>,
<kan.liang@linux.intel.com>, <daniel.sneddon@linux.intel.com>,
<pbonzini@redhat.com>, <sandipan.das@amd.com>,
<ilpo.jarvinen@linux.intel.com>, <peternewman@google.com>,
<maciej.wieczor-retman@intel.com>, <linux-doc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <eranian@google.com>,
<james.morse@arm.com>
Subject: Re: [PATCH v8 25/25] x86/resctrl: Introduce interface to modify assignment states of the groups
Date: Mon, 21 Oct 2024 10:20:09 -0700 [thread overview]
Message-ID: <9f3ab90b-0f35-4dcc-9996-4d6e941cbf2e@intel.com> (raw)
In-Reply-To: <d5d7706c-0c12-46bf-9a4d-9bd80db2c83f@amd.com>
Hi Babu,
On 10/21/24 10:04 AM, Moger, Babu wrote:
> On 10/15/24 22:43, Reinette Chatre wrote:
>> On 10/9/24 10:39 AM, Babu Moger wrote:
>>> +static int rdtgroup_process_flags(struct rdt_resource *r,
>>> + enum rdt_group_type rtype,
>>> + char *p_grp, char *c_grp, char *tok)
>>> +{
>>> + int op, mon_state, assign_state, unassign_state;
>>> + char *dom_str, *id_str, *op_str;
>>> + struct rdt_mon_domain *d;
>>> + struct rdtgroup *rdtgrp;
>>> + unsigned long dom_id;
>>> + int ret, found = 0;
>>> +
>>> + rdtgrp = rdtgroup_find_grp_by_name(rtype, p_grp, c_grp);
>>> +
>>> + if (!rdtgrp) {
>>> + rdt_last_cmd_puts("Not a valid resctrl group\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> +next:
>>> + if (!tok || tok[0] == '\0')
>>> + return 0;
>>> +
>>> + /* Start processing the strings for each domain */
>>> + dom_str = strim(strsep(&tok, ";"));
>>> +
>>> + op_str = strpbrk(dom_str, "=+-");
>>> +
>>> + if (op_str) {
>>> + op = *op_str;
>>> + } else {
>>> + rdt_last_cmd_puts("Missing operation =, +, - character\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + id_str = strsep(&dom_str, "=+-");
>>> +
>>> + /* Check for domain id '*' which means all domains */
>>> + if (id_str && *id_str == '*') {
>>> + d = NULL;
>>> + goto check_state;
>>> + } else if (!id_str || kstrtoul(id_str, 10, &dom_id)) {
>>> + rdt_last_cmd_puts("Missing domain id\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + /* Verify if the dom_id is valid */
>>> + list_for_each_entry(d, &r->mon_domains, hdr.list) {
>>> + if (d->hdr.id == dom_id) {
>>> + found = 1;
>>> + break;
>>> + }
>>> + }
>>> +
>>> + if (!found) {
>>> + rdt_last_cmd_printf("Invalid domain id %ld\n", dom_id);
>>> + return -EINVAL;
>>> + }
>>> +
>>> +check_state:
>>> + mon_state = rdtgroup_str_to_mon_state(dom_str);
>>> +
>>> + if (mon_state == ASSIGN_INVALID) {
>>> + rdt_last_cmd_puts("Invalid assign flag\n");
>>> + goto out_fail;
>>> + }
>>> +
>>> + assign_state = 0;
>>> + unassign_state = 0;
>>> +
>>> + switch (op) {
>>> + case '+':
>>> + if (mon_state == ASSIGN_NONE) {
>>> + rdt_last_cmd_puts("Invalid assign opcode\n");
>>> + goto out_fail;
>>> + }
>>> + assign_state = mon_state;
>>> + break;
>>> + case '-':
>>> + if (mon_state == ASSIGN_NONE) {
>>> + rdt_last_cmd_puts("Invalid assign opcode\n");
>>> + goto out_fail;
>>> + }
>>> + unassign_state = mon_state;
>>> + break;
>>> + case '=':
>>> + assign_state = mon_state;
>>> + unassign_state = (ASSIGN_TOTAL | ASSIGN_LOCAL) & ~assign_state;
>>> + break;
>>> + default:
>>> + break;
>>> + }
>>> +
>>> + if (unassign_state & ASSIGN_TOTAL) {
>>> + ret = rdtgroup_unassign_cntr_event(r, rdtgrp, d, QOS_L3_MBM_TOTAL_EVENT_ID);
>>> + if (ret)
>>> + goto out_fail;
>>> + }
>>> +
>>> + if (unassign_state & ASSIGN_LOCAL) {
>>> + ret = rdtgroup_unassign_cntr_event(r, rdtgrp, d, QOS_L3_MBM_LOCAL_EVENT_ID);
>>> + if (ret)
>>> + goto out_fail;
>>> + }
>>> +
>>> + if (assign_state & ASSIGN_TOTAL) {
>>> + ret = rdtgroup_assign_cntr_event(r, rdtgrp, d, QOS_L3_MBM_TOTAL_EVENT_ID);
>>> + if (ret)
>>> + goto out_fail;
>>> + }
>>> +
>>> + if (assign_state & ASSIGN_LOCAL) {
>>> + ret = rdtgroup_assign_cntr_event(r, rdtgrp, d, QOS_L3_MBM_LOCAL_EVENT_ID);
>>> + if (ret)
>>> + goto out_fail;
>>> + }
>>> +
>>> + goto next;
>>> +
>>> +out_fail:
>>
>> Is it possible to print a message to the command status to give some details about which
>> request failed? I am wondering about a scenario where a user changes multiple domains of
>> multiple groups, since the operation does not undo changes, it will fail without information
>> to user space about which setting triggered the failure and which settings succeeded.
>> This is similar to what is done when user attempts to move several tasks ... the error will
>> indicate which task triggered failure so that user space knows what completed successfully.
>
> Will add something like this on failure.
>
> rdt_last_cmd_printf("Total event assign failed on domain %d\n", dom_id);
The user may provide changes for several groups in a single write.
Could the CTRL_MON and MON group names also be printed? It is not clear
to me if it will be easier to print the flags the user provides or verbose text
that the flags translate to, that is "t" vs "Total event".
>>> +
>>> + return -EINVAL;
>>> +}
>>> +
>>> +static ssize_t rdtgroup_mbm_assign_control_write(struct kernfs_open_file *of,
>>> + char *buf, size_t nbytes, loff_t off)
>>> +{
>>> + struct rdt_resource *r = of->kn->parent->priv;
>>> + char *token, *cmon_grp, *mon_grp;
>>> + enum rdt_group_type rtype;
>>> + int ret;
>>> +
>>> + /* Valid input requires a trailing newline */
>>> + if (nbytes == 0 || buf[nbytes - 1] != '\n')
>>> + return -EINVAL;
>>> +
>>> + buf[nbytes - 1] = '\0';
>>> +
>>> + cpus_read_lock();
>>> + mutex_lock(&rdtgroup_mutex);
>>> +
>>> + if (!resctrl_arch_mbm_cntr_assign_enabled(r)) {
>>> + rdt_last_cmd_puts("mbm_cntr_assign mode is not enabled\n");
>>
>> Writing to last_cmd_status_buf here ...
>
> Sure.
>
>>
>>> + mutex_unlock(&rdtgroup_mutex);
>>> + cpus_read_unlock();
>>> + return -EINVAL;
>>> + }
>>> +
>>> + rdt_last_cmd_clear();
>>
>> ... but initializing buffer here.
>> Sidenote: This was an issue before. If you receive comments about
>> items in patches, please do check if those comments apply to other patches also.
>
> Missed it.
>
>>
>>> +
>>> + while ((token = strsep(&buf, "\n")) != NULL) {
>>> + if (strstr(token, "/")) {
What is the purpose of this strstr() call?
>>> + /*
>>> + * The write command follows the following format:
>>> + * “<CTRL_MON group>/<MON group>/<domain_id><opcode><flags>”
>>> + * Extract the CTRL_MON group.
>>> + */
>>> + cmon_grp = strsep(&token, "/");
>>> +
>>> + /*
>>> + * Extract the MON_GROUP.
>>> + * strsep returns empty string for contiguous delimiters.
>>> + * Empty mon_grp here means it is a RDTCTRL_GROUP.
>>> + */
>>> + mon_grp = strsep(&token, "/");
>>> +
>>> + if (*mon_grp == '\0')
>>> + rtype = RDTCTRL_GROUP;
>>> + else
>>> + rtype = RDTMON_GROUP;
>>> +
>>> + ret = rdtgroup_process_flags(r, rtype, cmon_grp, mon_grp, token);
>>> + if (ret)
>>> + break;
>>> + }
>>> + }
>>> +
>>> + mutex_unlock(&rdtgroup_mutex);
>>> + cpus_read_unlock();
>>> +
>>> + return ret ?: nbytes;
>>> +}
>>> +
>>> #ifdef CONFIG_PROC_CPU_RESCTRL
>>>
>>> /*
>>> @@ -2328,9 +2558,10 @@ static struct rftype res_common_files[] = {
>>> },
>>> {
>>> .name = "mbm_assign_control",
>>> - .mode = 0444,
>>> + .mode = 0644,
>>> .kf_ops = &rdtgroup_kf_single_ops,
>>> .seq_show = rdtgroup_mbm_assign_control_show,
>>> + .write = rdtgroup_mbm_assign_control_write,
>>> },
>>> {
>>> .name = "cpus_list",
>>
>> On a high level this looks ok but this code needs to be more robust. This will parse
>> data from user space that may include all kinds of input ... think malicious user or
>> a buggy script. I am not able to test this code but I tried to work through what will
>> happen under some wrong input and found some issues. For example, if user space provides
>> input like '//\n' then rdtgroup_process_flags() will be called with token == NULL. This will
>> result in rdtgroup_process_flags() returning "success", but fortunately do nothing, for
>> this invalid input. A more severe example is with input like '//0=\n', from what I can tell
>> this will result in rdtgroup_str_to_mon_state() called with dom_str==NULL that will treat
>> this as ASSIGN_NONE and proceed as if user provided '//0=_'.
>> This was just some scenarios with basic input that could be typos, no real stress tests.
>> I stopped here though since I believe it is already clear this needs to be more robust.
>> Please do test this interface by exercising it with invalid input and corner cases.
>
> Agree.
>
> But, tested the cases you mentioned above. It seems to handle as expected.
>
> # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_control
> //0=tl;1=tl;2=tl;3=tl;4=tl;5=tl;6=tl;7=tl;8=tl;9=tl;10=tl;11=tl;
>
> #echo '//\n' > /sys/fs/resctrl/info/L3_MON/mbm_assign_control
> bash: echo: write error: Invalid argument
>
> # cat /sys/fs/resctrl/info/last_cmd_status
> Missing operation =, +, - character
>
>
> #echo '//0=\n' > /sys/fs/resctrl/info/L3_MON/mbm_assign_control
> bash: echo: write error: Invalid argument
>
> #cat /sys/fs/resctrl/info/last_cmd_status
> Invalid assign flag
>
> #echo '/0=\n' > /sys/fs/resctrl/info/L3_MON/mbm_assign_control
> bash: echo: write error: Invalid argument
> # cat /sys/fs/resctrl/info/last_cmd_status
> Not a valid resctrl group
>
>
> The assign state did not change.
> #cat /sys/fs/resctrl/info/L3_MON/mbm_assign_control
> //0=tl;1=tl;2=tl;3=tl;4=tl;5=tl;6=tl;7=tl;8=tl;9=tl;10=tl;11=tl;
>
> Sure. will test some more combinations to be sure.
hmmm ... these are not quite the examples I shared since from what I can
tell it adds a second \n that impacts the processing of string.
Could you please try:
# echo '//' > /sys/fs/resctrl/info/L3_MON/mbm_assign_control
and
# echo '//0=' > /sys/fs/resctrl/info/L3_MON/mbm_assign_control
Reinette
next prev parent reply other threads:[~2024-10-21 17:20 UTC|newest]
Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 17:39 [PATCH v8 00/25] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Babu Moger
2024-10-09 17:39 ` [PATCH v8 01/25] x86/cpufeatures: Add support for " Babu Moger
2024-10-09 17:39 ` [PATCH v8 02/25] x86/resctrl: Add ABMC feature in the command line options Babu Moger
2024-10-16 3:06 ` Reinette Chatre
2024-10-09 17:39 ` [PATCH v8 03/25] x86/resctrl: Consolidate monitoring related data from rdt_resource Babu Moger
2024-10-09 17:39 ` [PATCH v8 04/25] x86/resctrl: Detect Assignable Bandwidth Monitoring feature details Babu Moger
2024-10-16 3:06 ` Reinette Chatre
2024-10-09 17:39 ` [PATCH v8 05/25] x86/resctrl: Introduce resctrl_file_fflags_init() to initialize fflags Babu Moger
2024-10-09 17:39 ` [PATCH v8 06/25] x86/resctrl: Add support to enable/disable AMD ABMC feature Babu Moger
2024-10-11 18:14 ` Tony Luck
2024-10-11 20:53 ` Moger, Babu
2024-10-16 3:07 ` Reinette Chatre
2024-10-09 17:39 ` [PATCH v8 07/25] x86/resctrl: Introduce the interface to display monitor mode Babu Moger
2024-10-09 22:42 ` Tony Luck
2024-10-10 14:54 ` Moger, Babu
2024-10-10 15:07 ` Luck, Tony
2024-10-10 15:30 ` Moger, Babu
2024-10-10 16:02 ` Luck, Tony
2024-10-11 22:24 ` Reinette Chatre
2024-10-14 15:16 ` Moger, Babu
2024-10-16 3:12 ` Reinette Chatre
2024-10-16 15:57 ` Moger, Babu
2024-10-16 16:25 ` Reinette Chatre
2024-10-09 17:39 ` [PATCH v8 08/25] x86/resctrl: Introduce interface to display number of monitoring counters Babu Moger
2024-10-09 22:49 ` Tony Luck
2024-10-10 15:12 ` Moger, Babu
2024-10-10 15:58 ` Luck, Tony
2024-10-10 16:57 ` Moger, Babu
2024-10-10 17:08 ` Luck, Tony
2024-10-10 18:36 ` Moger, Babu
2024-10-10 18:57 ` Luck, Tony
2024-10-10 20:32 ` Moger, Babu
2024-10-11 17:44 ` Tony Luck
2024-10-11 20:49 ` Moger, Babu
2024-10-11 21:36 ` Tony Luck
2024-10-14 16:46 ` Reinette Chatre
2024-10-14 17:20 ` Moger, Babu
2024-10-14 17:49 ` Luck, Tony
2024-10-14 19:21 ` Moger, Babu
2024-10-14 19:51 ` Luck, Tony
2024-10-14 20:05 ` Reinette Chatre
2024-10-14 20:32 ` Moger, Babu
2024-10-24 17:29 ` Moger, Babu
2024-10-24 17:37 ` Luck, Tony
2024-10-25 20:31 ` Moger, Babu
2024-10-14 16:59 ` Reinette Chatre
2024-10-14 19:23 ` Moger, Babu
2024-10-14 16:25 ` Reinette Chatre
2024-10-14 17:46 ` Moger, Babu
2024-10-14 18:30 ` Reinette Chatre
2024-10-14 18:51 ` Moger, Babu
2024-10-09 17:39 ` [PATCH v8 09/25] x86/resctrl: Add __init attribute to dom_data_init() Babu Moger
2024-10-16 3:13 ` Reinette Chatre
2024-10-16 17:32 ` Moger, Babu
2024-10-16 18:55 ` Reinette Chatre
2024-10-16 20:18 ` Moger, Babu
2024-10-09 17:39 ` [PATCH v8 10/25] x86/resctrl: Introduce bitmap mbm_cntr_free_map to track assignable counters Babu Moger
2024-10-16 3:14 ` Reinette Chatre
2024-10-17 16:55 ` Moger, Babu
2024-10-09 17:39 ` [PATCH v8 11/25] x86/resctrl: Introduce mbm_total_cfg and mbm_local_cfg in struct rdt_hw_mon_domain Babu Moger
2024-10-16 3:15 ` Reinette Chatre
2024-10-09 17:39 ` [PATCH v8 12/25] x86/resctrl: Remove MSR reading of event configuration value Babu Moger
2024-10-16 3:16 ` Reinette Chatre
2024-10-17 17:59 ` Moger, Babu
2024-10-09 17:39 ` [PATCH v8 13/25] x86/resctrl: Introduce mbm_cntr_map to track assignable counters at domain Babu Moger
2024-10-16 3:19 ` Reinette Chatre
2024-10-09 17:39 ` [PATCH v8 14/25] x86/resctrl: Add data structures and definitions for ABMC assignment Babu Moger
2024-10-16 3:21 ` Reinette Chatre
2024-10-17 18:52 ` Moger, Babu
2024-10-17 21:13 ` Reinette Chatre
2024-10-17 23:02 ` Moger, Babu
2024-10-09 17:39 ` [PATCH v8 15/25] x86/resctrl: Introduce cntr_id in mongroup for assignments Babu Moger
2024-10-16 3:22 ` Reinette Chatre
2024-10-17 19:19 ` Moger, Babu
2024-10-09 17:39 ` [PATCH v8 16/25] x86/resctrl: Implement resctrl_arch_config_cntr() to assign a counter with ABMC Babu Moger
2024-10-16 3:23 ` Reinette Chatre
2024-10-17 22:44 ` Moger, Babu
2024-10-09 17:39 ` [PATCH v8 17/25] x86/resctrl: Add the interface to assign/update counter assignment Babu Moger
2024-10-16 3:25 ` Reinette Chatre
2024-10-17 22:56 ` Moger, Babu
2024-10-18 15:59 ` Reinette Chatre
2024-10-21 14:40 ` Moger, Babu
2024-10-21 15:31 ` Reinette Chatre
2024-10-22 1:15 ` Moger, Babu
2024-10-09 17:39 ` [PATCH v8 18/25] x86/resctrl: Add the interface to unassign a MBM counter Babu Moger
2024-10-16 3:29 ` Reinette Chatre
2024-10-17 23:11 ` Moger, Babu
2024-10-18 16:06 ` Reinette Chatre
2024-10-09 17:39 ` [PATCH v8 19/25] x86/resctrl: Auto assign/unassign counters when mbm_cntr_assign is enabled Babu Moger
2024-10-11 17:17 ` Tony Luck
2024-10-11 21:17 ` Moger, Babu
2024-10-11 21:33 ` Luck, Tony
2024-10-14 15:43 ` Moger, Babu
2024-10-14 16:18 ` Luck, Tony
2024-10-14 16:35 ` Moger, Babu
2024-10-15 2:39 ` Reinette Chatre
2024-10-15 15:43 ` Moger, Babu
2024-10-15 16:57 ` Luck, Tony
2024-10-15 17:18 ` Reinette Chatre
2024-10-15 20:42 ` Moger, Babu
2024-10-16 3:30 ` Reinette Chatre
2024-10-18 14:22 ` Moger, Babu
2024-10-09 17:39 ` [PATCH v8 20/25] x86/resctrl: Report "Unassigned" for MBM events in mbm_cntr_assign mode Babu Moger
2024-10-11 17:23 ` Tony Luck
2024-10-11 21:21 ` Moger, Babu
2024-10-16 3:31 ` Reinette Chatre
2024-10-18 14:31 ` Moger, Babu
2024-10-09 17:39 ` [PATCH v8 21/25] x86/resctrl: Introduce the interface to switch between monitor modes Babu Moger
2024-10-16 3:36 ` Reinette Chatre
2024-10-18 15:13 ` Moger, Babu
2024-10-09 17:39 ` [PATCH v8 22/25] x86/resctrl: Configure mbm_cntr_assign mode if supported Babu Moger
2024-10-09 17:39 ` [PATCH v8 23/25] x86/resctrl: Update assignments on event configuration changes Babu Moger
2024-10-16 3:40 ` Reinette Chatre
2024-10-18 15:50 ` Moger, Babu
2024-10-09 17:39 ` [PATCH v8 24/25] x86/resctrl: Introduce interface to list assignment states of all the groups Babu Moger
2024-10-16 3:40 ` Reinette Chatre
2024-10-21 14:56 ` Moger, Babu
2024-10-09 17:39 ` [PATCH v8 25/25] x86/resctrl: Introduce interface to modify assignment states of " Babu Moger
2024-10-16 3:43 ` Reinette Chatre
2024-10-21 17:04 ` Moger, Babu
2024-10-21 17:20 ` Reinette Chatre [this message]
2024-10-22 1:12 ` Moger, Babu
2024-10-16 3:05 ` [PATCH v8 00/25] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Reinette Chatre
2024-10-21 17:09 ` Moger, Babu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9f3ab90b-0f35-4dcc-9996-4d6e941cbf2e@intel.com \
--to=reinette.chatre@intel.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=daniel.sneddon@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=eranian@google.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=james.morse@arm.com \
--cc=jithu.joseph@intel.com \
--cc=jmattson@google.com \
--cc=jpoimboe@kernel.org \
--cc=kai.huang@intel.com \
--cc=kan.liang@linux.intel.com \
--cc=kim.phillips@amd.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=leitao@debian.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=maciej.wieczor-retman@intel.com \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peternewman@google.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=sandipan.das@amd.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=x86@kernel.org \
--cc=yanjiewtw@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®