The commit 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display
monitoring modes") introduced CONFIG_RESCTRL_ASSIGN_FIXED but did not add
the kconfig entry. Add this.

Also, take the opportunity ensure that any user attempt to change the
assign mode fails from the resctrl code rather than delegating to the arch
specific code and let the user know by adding a message in last_cmd_status.

Fixes: 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display monitoring modes")
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
 fs/resctrl/Kconfig   | 8 ++++++++
 fs/resctrl/monitor.c | 6 ++++++
 2 files changed, 14 insertions(+)

diff --git a/fs/resctrl/Kconfig b/fs/resctrl/Kconfig
index 21671301bd8a..bdf9e11502fa 100644
--- a/fs/resctrl/Kconfig
+++ b/fs/resctrl/Kconfig
@@ -37,3 +37,11 @@ config RESCTRL_RMID_DEPENDS_ON_CLOSID
 	  Enabled by the architecture when the RMID values depend on the CLOSID.
 	  This causes the CLOSID allocator to search for CLOSID with clean
 	  RMID.
+
+config RESCTRL_ASSIGN_FIXED
+	bool
+	depends on RESCTRL_FS
+	help
+	 Enabled by the architecture when the counter assignment mode is not
+	 configurable. This ensures that counter assignment is not advertised as
+	 configurable and configuration attempts fail.
diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c
index 572a9925bd6c..888e303c18a2 100644
--- a/fs/resctrl/monitor.c
+++ b/fs/resctrl/monitor.c
@@ -1434,6 +1434,12 @@ ssize_t resctrl_mbm_assign_mode_write(struct kernfs_open_file *of, char *buf,
 
 	rdt_last_cmd_clear();
 
+	if (IS_ENABLED(CONFIG_RESCTRL_ASSIGN_FIXED)) {
+		ret = -EINVAL;
+		rdt_last_cmd_puts("assign mode is not configurable\n");
+		goto out_unlock;
+	}
+
 	if (!strcmp(buf, "default")) {
 		enable = 0;
 	} else if (!strcmp(buf, "mbm_event")) {
-- 
2.43.0

Hi Ben,

Per subject, the Kconfig entry has not really been missing but has instead been
intentionally left undefined which is handled correctly by IS_ENABLED(). The
plans/usage surrounding CONFIG_RESCTRL_ASSIGN_FIXED can be found in the same
commit used in "Fixes" tag. Adding the definition as a fix to the patch that
documents that it is intentionally left undefined is unexpected.

This patch is just following existing plan that CONFIG_RESCTRL_ASSIGN_FIXED
will be defined at the time Arm support needs it, no? Folks using "Fixes" to
determine if a change needs to be backported will find no benefit from this
and terming it a fix will just cause unnecessary work.

On 1/13/26 6:49 AM, Ben Horgan wrote:
> The commit 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display
> monitoring modes") introduced CONFIG_RESCTRL_ASSIGN_FIXED but did not add
> the kconfig entry. Add this.
>
> Also, take the opportunity ensure that any user attempt to change the
> assign mode fails from the resctrl code rather than delegating to the arch
> specific code and let the user know by adding a message in last_cmd_status.

Why *any* attempt? Avoiding delegating to arch seems ok as a goal but this change
additionally changes interface with user space. Current behavior when user writes
existing mode to the file is to just return success. For example, if current mode
is "default" and user writes "default". This patch changes this behavior to fail
instead. Is this intended?
 
> Fixes: 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display monitoring modes")
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
>  fs/resctrl/Kconfig   | 8 ++++++++
>  fs/resctrl/monitor.c | 6 ++++++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/fs/resctrl/Kconfig b/fs/resctrl/Kconfig
> index 21671301bd8a..bdf9e11502fa 100644
> --- a/fs/resctrl/Kconfig
> +++ b/fs/resctrl/Kconfig
> @@ -37,3 +37,11 @@ config RESCTRL_RMID_DEPENDS_ON_CLOSID
>  	  Enabled by the architecture when the RMID values depend on the CLOSID.
>  	  This causes the CLOSID allocator to search for CLOSID with clean
>  	  RMID.
> +
> +config RESCTRL_ASSIGN_FIXED
> +	bool
> +	depends on RESCTRL_FS
> +	help
> +	 Enabled by the architecture when the counter assignment mode is not
> +	 configurable. This ensures that counter assignment is not advertised as
> +	 configurable and configuration attempts fail.
> diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c
> index 572a9925bd6c..888e303c18a2 100644
> --- a/fs/resctrl/monitor.c
> +++ b/fs/resctrl/monitor.c
> @@ -1434,6 +1434,12 @@ ssize_t resctrl_mbm_assign_mode_write(struct kernfs_open_file *of, char *buf,
>  
>  	rdt_last_cmd_clear();
>  
> +	if (IS_ENABLED(CONFIG_RESCTRL_ASSIGN_FIXED)) {
> +		ret = -EINVAL;
> +		rdt_last_cmd_puts("assign mode is not configurable\n");
> +		goto out_unlock;
> +	}
> +
>  	if (!strcmp(buf, "default")) {
>  		enable = 0;
>  	} else if (!strcmp(buf, "mbm_event")) {

Reinette

Hi Reinette,

On 1/14/26 19:09, Reinette Chatre wrote:
> Hi Ben,
> 
> Per subject, the Kconfig entry has not really been missing but has instead been
> intentionally left undefined which is handled correctly by IS_ENABLED(). The
> plans/usage surrounding CONFIG_RESCTRL_ASSIGN_FIXED can be found in the same
> commit used in "Fixes" tag. Adding the definition as a fix to the patch that
> documents that it is intentionally left undefined is unexpected.
> 
> This patch is just following existing plan that CONFIG_RESCTRL_ASSIGN_FIXED
> will be defined at the time Arm support needs it, no? Folks using "Fixes" to
> determine if a change needs to be backported will find no benefit from this
> and terming it a fix will just cause unnecessary work.

Fair enough. I didn't follow that discussion. I'll drop the fixes tag on
a respin.

> 
> On 1/13/26 6:49 AM, Ben Horgan wrote:
>> The commit 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display
>> monitoring modes") introduced CONFIG_RESCTRL_ASSIGN_FIXED but did not add
>> the kconfig entry. Add this.
>>
>> Also, take the opportunity ensure that any user attempt to change the
>> assign mode fails from the resctrl code rather than delegating to the arch
>> specific code and let the user know by adding a message in last_cmd_status.
> 
> Why *any* attempt? Avoiding delegating to arch seems ok as a goal but this change
> additionally changes interface with user space. Current behavior when user writes
> existing mode to the file is to just return success. For example, if current mode
> is "default" and user writes "default". This patch changes this behavior to fail
> instead. Is this intended?

Intended but as you point out, it would be best to accept the current
value without error for maximum compatibility between architectures.
I'll update the config option help text to reflect this. Was the help
text also discussed previously?

>  
>> Fixes: 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display monitoring modes")
>> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
>> ---
>>  fs/resctrl/Kconfig   | 8 ++++++++
>>  fs/resctrl/monitor.c | 6 ++++++
>>  2 files changed, 14 insertions(+)
>>
>> diff --git a/fs/resctrl/Kconfig b/fs/resctrl/Kconfig
>> index 21671301bd8a..bdf9e11502fa 100644
>> --- a/fs/resctrl/Kconfig
>> +++ b/fs/resctrl/Kconfig
>> @@ -37,3 +37,11 @@ config RESCTRL_RMID_DEPENDS_ON_CLOSID
>>  	  Enabled by the architecture when the RMID values depend on the CLOSID.
>>  	  This causes the CLOSID allocator to search for CLOSID with clean
>>  	  RMID.
>> +
>> +config RESCTRL_ASSIGN_FIXED
>> +	bool
>> +	depends on RESCTRL_FS
>> +	help
>> +	 Enabled by the architecture when the counter assignment mode is not
>> +	 configurable. This ensures that counter assignment is not advertised as
>> +	 configurable and configuration attempts fail.
>> diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c
>> index 572a9925bd6c..888e303c18a2 100644
>> --- a/fs/resctrl/monitor.c
>> +++ b/fs/resctrl/monitor.c
>> @@ -1434,6 +1434,12 @@ ssize_t resctrl_mbm_assign_mode_write(struct kernfs_open_file *of, char *buf,
>>  
>>  	rdt_last_cmd_clear();
>>  
>> +	if (IS_ENABLED(CONFIG_RESCTRL_ASSIGN_FIXED)) {
>> +		ret = -EINVAL;
>> +		rdt_last_cmd_puts("assign mode is not configurable\n");
>> +		goto out_unlock;
>> +	}
>> +
>>  	if (!strcmp(buf, "default")) {
>>  		enable = 0;
>>  	} else if (!strcmp(buf, "mbm_event")) {
> 
> Reinette

Thanks,

Ben

Hi Ben,

On 1/15/26 2:32 AM, Ben Horgan wrote:
> On 1/14/26 19:09, Reinette Chatre wrote:
>> On 1/13/26 6:49 AM, Ben Horgan wrote:
>>> The commit 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display
>>> monitoring modes") introduced CONFIG_RESCTRL_ASSIGN_FIXED but did not add
>>> the kconfig entry. Add this.
>>>
>>> Also, take the opportunity ensure that any user attempt to change the
>>> assign mode fails from the resctrl code rather than delegating to the arch
>>> specific code and let the user know by adding a message in last_cmd_status.
>>
>> Why *any* attempt? Avoiding delegating to arch seems ok as a goal but this change
>> additionally changes interface with user space. Current behavior when user writes
>> existing mode to the file is to just return success. For example, if current mode
>> is "default" and user writes "default". This patch changes this behavior to fail
>> instead. Is this intended?
> 
> Intended but as you point out, it would be best to accept the current
> value without error for maximum compatibility between architectures.
> I'll update the config option help text to reflect this. Was the help
> text also discussed previously?

It is not clear to me which help text you are referring to. Could you
please point me to it?

Reinette

Hi Reinette,

On 1/15/26 15:37, Reinette Chatre wrote:
> Hi Ben,
> 
> On 1/15/26 2:32 AM, Ben Horgan wrote:
>> On 1/14/26 19:09, Reinette Chatre wrote:
>>> On 1/13/26 6:49 AM, Ben Horgan wrote:
>>>> The commit 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display
>>>> monitoring modes") introduced CONFIG_RESCTRL_ASSIGN_FIXED but did not add
>>>> the kconfig entry. Add this.
>>>>
>>>> Also, take the opportunity ensure that any user attempt to change the
>>>> assign mode fails from the resctrl code rather than delegating to the arch
>>>> specific code and let the user know by adding a message in last_cmd_status.
>>>
>>> Why *any* attempt? Avoiding delegating to arch seems ok as a goal but this change
>>> additionally changes interface with user space. Current behavior when user writes
>>> existing mode to the file is to just return success. For example, if current mode
>>> is "default" and user writes "default". This patch changes this behavior to fail
>>> instead. Is this intended?
>>
>> Intended but as you point out, it would be best to accept the current
>> value without error for maximum compatibility between architectures.
>> I'll update the config option help text to reflect this. Was the help
>> text also discussed previously?
> 
> It is not clear to me which help text you are referring to. Could you
> please point me to it?

I just mean the description in Kconfig. Maybe I'm using the wrong
terminology?

From this patch:
    help
     Enabled by the architecture when the counter assignment mode is not
     configurable. This ensures that counter assignment is not
advertised as
     configurable and configuration attempts fail.

> 
> Reinette

Thanks,

Ben

Hi Ben,

On 1/15/26 7:46 AM, Ben Horgan wrote:
> Hi Reinette,
> 
> On 1/15/26 15:37, Reinette Chatre wrote:
>> Hi Ben,
>>
>> On 1/15/26 2:32 AM, Ben Horgan wrote:
>>> On 1/14/26 19:09, Reinette Chatre wrote:
>>>> On 1/13/26 6:49 AM, Ben Horgan wrote:
>>>>> The commit 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display
>>>>> monitoring modes") introduced CONFIG_RESCTRL_ASSIGN_FIXED but did not add
>>>>> the kconfig entry. Add this.
>>>>>
>>>>> Also, take the opportunity ensure that any user attempt to change the
>>>>> assign mode fails from the resctrl code rather than delegating to the arch
>>>>> specific code and let the user know by adding a message in last_cmd_status.
>>>>
>>>> Why *any* attempt? Avoiding delegating to arch seems ok as a goal but this change
>>>> additionally changes interface with user space. Current behavior when user writes
>>>> existing mode to the file is to just return success. For example, if current mode
>>>> is "default" and user writes "default". This patch changes this behavior to fail
>>>> instead. Is this intended?
>>>
>>> Intended but as you point out, it would be best to accept the current
>>> value without error for maximum compatibility between architectures.
>>> I'll update the config option help text to reflect this. Was the help
>>> text also discussed previously?
>>
>> It is not clear to me which help text you are referring to. Could you
>> please point me to it?
> 
> I just mean the description in Kconfig. Maybe I'm using the wrong
> terminology?

Counter assignment mode is the right terminology and used throughout the resctrl
documentation.

> 
> From this patch:
>     help
>      Enabled by the architecture when the counter assignment mode is not
>      configurable. This ensures that counter assignment is not

nit: I recommend above "counter assignment" be "counter assignment mode" to be specific
that this is about the *mode* being configurable and not talking about the actual counter
assignment.

Also please ensure that the formatting adheres to the guidance in "Kconfig configuration
files" in Documentation/process/coding-style.rst. Specifically, "help text is indented an
additional two spaces".

> advertised as
>      configurable and configuration attempts fail.

"configuration attempts" -> "attempts to change counter assignment mode"?

As a sidenote, if I understand correctly, MPAM can actually support changing the mode
when it is in "free running" mode (when there are enough counters/monitors available). It
seems to me these systems *could* advertise something like:

	# cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
	[default]
	mbm_event

It is not clear to me if there is a scenario that would benefit from such capability though.
I just bring this up to confirm whether CONFIG_RESCTRL_ASSIGN_FIXED is something that
MPAM enabling wants to enforce for all platforms?

Reinette

Hi Reinette,

On 1/15/26 17:19, Reinette Chatre wrote:
> Hi Ben,
> 
> On 1/15/26 7:46 AM, Ben Horgan wrote:
>> Hi Reinette,
>>
>> On 1/15/26 15:37, Reinette Chatre wrote:
>>> Hi Ben,
>>>
>>> On 1/15/26 2:32 AM, Ben Horgan wrote:
>>>> On 1/14/26 19:09, Reinette Chatre wrote:
>>>>> On 1/13/26 6:49 AM, Ben Horgan wrote:
>>>>>> The commit 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display
>>>>>> monitoring modes") introduced CONFIG_RESCTRL_ASSIGN_FIXED but did not add
>>>>>> the kconfig entry. Add this.
>>>>>>
>>>>>> Also, take the opportunity ensure that any user attempt to change the
>>>>>> assign mode fails from the resctrl code rather than delegating to the arch
>>>>>> specific code and let the user know by adding a message in last_cmd_status.
>>>>>
>>>>> Why *any* attempt? Avoiding delegating to arch seems ok as a goal but this change
>>>>> additionally changes interface with user space. Current behavior when user writes
>>>>> existing mode to the file is to just return success. For example, if current mode
>>>>> is "default" and user writes "default". This patch changes this behavior to fail
>>>>> instead. Is this intended?
>>>>
>>>> Intended but as you point out, it would be best to accept the current
>>>> value without error for maximum compatibility between architectures.
>>>> I'll update the config option help text to reflect this. Was the help
>>>> text also discussed previously?
>>>
>>> It is not clear to me which help text you are referring to. Could you
>>> please point me to it?
>>
>> I just mean the description in Kconfig. Maybe I'm using the wrong
>> terminology?
> 
> Counter assignment mode is the right terminology and used throughout the resctrl
> documentation.

Ack.

> 
>>
>> From this patch:
>>     help
>>      Enabled by the architecture when the counter assignment mode is not
>>      configurable. This ensures that counter assignment is not
> 
> nit: I recommend above "counter assignment" be "counter assignment mode" to be specific
> that this is about the *mode* being configurable and not talking about the actual counter
> assignment.
> 
> Also please ensure that the formatting adheres to the guidance in "Kconfig configuration
> files" in Documentation/process/coding-style.rst. Specifically, "help text is indented an
> additional two spaces".

Will do.

> 
>> advertised as
>>      configurable and configuration attempts fail.
> 
> "configuration attempts" -> "attempts to change counter assignment mode"?

Sure.

> 
> As a sidenote, if I understand correctly, MPAM can actually support changing the mode
> when it is in "free running" mode (when there are enough counters/monitors available). It
> seems to me these systems *could* advertise something like:
> 
> 	# cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
> 	[default]
> 	mbm_event
> 
> It is not clear to me if there is a scenario that would benefit from such capability though.
> I just bring this up to confirm whether CONFIG_RESCTRL_ASSIGN_FIXED is something that
> MPAM enabling wants to enforce for all platforms?

On a platform with sufficient monitors to have one per rmid idx
(num_partid * num_pmg) it would be architecturally possible to use
either mode but the policy decision is that the driver will always
decides which mode to use at probe based on whether  there are
sufficient monitors or not. Hence, we want to enforce
CONFIG_RESCTRL_ASSIGN_FIXED for all platforms.

> 
> Reinette

Thanks,

Ben

Hi Ben,

On 1/13/26 08:49, Ben Horgan wrote:
> The commit 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display
> monitoring modes") introduced CONFIG_RESCTRL_ASSIGN_FIXED but did not add
> the kconfig entry. Add this.
Add this -> Add the missing configuration option  or Add the missing 
Kconfig option. ?
>
> Also, take the opportunity ensure that any user attempt to change the
> assign mode fails from the resctrl code rather than delegating to the arch

assign mode -> counter assignment mode


> specific code and let the user know by adding a message in last_cmd_status.
>
> Fixes: 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display monitoring modes")
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
>   fs/resctrl/Kconfig   | 8 ++++++++
>   fs/resctrl/monitor.c | 6 ++++++
>   2 files changed, 14 insertions(+)
>
> diff --git a/fs/resctrl/Kconfig b/fs/resctrl/Kconfig
> index 21671301bd8a..bdf9e11502fa 100644
> --- a/fs/resctrl/Kconfig
> +++ b/fs/resctrl/Kconfig
> @@ -37,3 +37,11 @@ config RESCTRL_RMID_DEPENDS_ON_CLOSID
>   	  Enabled by the architecture when the RMID values depend on the CLOSID.
>   	  This causes the CLOSID allocator to search for CLOSID with clean
>   	  RMID.
> +
> +config RESCTRL_ASSIGN_FIXED
> +	bool
> +	depends on RESCTRL_FS
> +	help
> +	 Enabled by the architecture when the counter assignment mode is not
> +	 configurable. This ensures that counter assignment is not advertised as
> +	 configurable and configuration attempts fail.
> diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c
> index 572a9925bd6c..888e303c18a2 100644
> --- a/fs/resctrl/monitor.c
> +++ b/fs/resctrl/monitor.c
> @@ -1434,6 +1434,12 @@ ssize_t resctrl_mbm_assign_mode_write(struct kernfs_open_file *of, char *buf,
>   
>   	rdt_last_cmd_clear();
>   
> +	if (IS_ENABLED(CONFIG_RESCTRL_ASSIGN_FIXED)) {
> +		ret = -EINVAL;
> +		rdt_last_cmd_puts("assign mode is not configurable\n");

assign mode -> counter assignment mode


> +		goto out_unlock;
> +	}
> +
>   	if (!strcmp(buf, "default")) {
>   		enable = 0;
>   	} else if (!strcmp(buf, "mbm_event")) {

Hi Babu,

On 1/13/26 19:10, Babu Moger wrote:
> Hi Ben,
> 
> On 1/13/26 08:49, Ben Horgan wrote:
>> The commit 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display
>> monitoring modes") introduced CONFIG_RESCTRL_ASSIGN_FIXED but did not add
>> the kconfig entry. Add this.
> Add this -> Add the missing configuration option  or Add the missing
> Kconfig option. ?

I'll update the commit message to make it clearer that the change is
adding a Kconfig option that was previously intentionally left
undefined. (As per Reinette's review comments.)

>>
>> Also, take the opportunity ensure that any user attempt to change the
>> assign mode fails from the resctrl code rather than delegating to the
>> arch
> 
> assign mode -> counter assignment mode

Ack.

> 
> 
>> specific code and let the user know by adding a message in
>> last_cmd_status.
>>
>> Fixes: 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display
>> monitoring modes")
>> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
>> ---
>>   fs/resctrl/Kconfig   | 8 ++++++++
>>   fs/resctrl/monitor.c | 6 ++++++
>>   2 files changed, 14 insertions(+)
>>
>> diff --git a/fs/resctrl/Kconfig b/fs/resctrl/Kconfig
>> index 21671301bd8a..bdf9e11502fa 100644
>> --- a/fs/resctrl/Kconfig
>> +++ b/fs/resctrl/Kconfig
>> @@ -37,3 +37,11 @@ config RESCTRL_RMID_DEPENDS_ON_CLOSID
>>         Enabled by the architecture when the RMID values depend on the
>> CLOSID.
>>         This causes the CLOSID allocator to search for CLOSID with clean
>>         RMID.
>> +
>> +config RESCTRL_ASSIGN_FIXED
>> +    bool
>> +    depends on RESCTRL_FS
>> +    help
>> +     Enabled by the architecture when the counter assignment mode is not
>> +     configurable. This ensures that counter assignment is not
>> advertised as
>> +     configurable and configuration attempts fail.
>> diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c
>> index 572a9925bd6c..888e303c18a2 100644
>> --- a/fs/resctrl/monitor.c
>> +++ b/fs/resctrl/monitor.c
>> @@ -1434,6 +1434,12 @@ ssize_t resctrl_mbm_assign_mode_write(struct
>> kernfs_open_file *of, char *buf,
>>         rdt_last_cmd_clear();
>>   +    if (IS_ENABLED(CONFIG_RESCTRL_ASSIGN_FIXED)) {
>> +        ret = -EINVAL;
>> +        rdt_last_cmd_puts("assign mode is not configurable\n");
> 
> assign mode -> counter assignment mode

Ack

> 
> 
>> +        goto out_unlock;
>> +    }
>> +
>>       if (!strcmp(buf, "default")) {
>>           enable = 0;
>>       } else if (!strcmp(buf, "mbm_event")) {


Thanks,

Ben