linux-kernel - Re: [PATCH v15 24/34] fs/resctrl: Report 'Unassigned' for MBM events in mbm

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <37f2b5b1-0e99-45dc-bba3-c8c22fb298cf@amd.com>
Date: Tue, 22 Jul 2025 19:26:56 -0500
From: "Moger, Babu" <bmoger@....com>
To: Reinette Chatre <reinette.chatre@...el.com>, babu.moger@....com,
 corbet@....net, tony.luck@...el.com, james.morse@....com,
 tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com
Cc: Dave.Martin@....com, x86@...nel.org, hpa@...or.com,
 akpm@...ux-foundation.org, paulmck@...nel.org, rostedt@...dmis.org,
 Neeraj.Upadhyay@....com, david@...hat.com, arnd@...db.de, fvdl@...gle.com,
 seanjc@...gle.com, jpoimboe@...nel.org, pawan.kumar.gupta@...ux.intel.com,
 xin@...or.com, manali.shukla@....com, tao1.su@...ux.intel.com,
 sohil.mehta@...el.com, kai.huang@...el.com, xiaoyao.li@...el.com,
 peterz@...radead.org, xin3.li@...el.com, kan.liang@...ux.intel.com,
 mario.limonciello@....com, thomas.lendacky@....com, perry.yuan@....com,
 gautham.shenoy@....com, chang.seok.bae@...el.com, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, peternewman@...gle.com, eranian@...gle.com
Subject: Re: [PATCH v15 24/34] fs/resctrl: Report 'Unassigned' for MBM events
 in mbm_event mode

Hi Reinette,

On 7/22/2025 6:28 PM, Reinette Chatre wrote:
> Hi Babu,
> 
> On 7/22/25 11:15 AM, Moger, Babu wrote:
>> Hi Reinette,
>>
>> On 7/17/25 22:53, Reinette Chatre wrote:
>>> Hi Babu,
>>>
>>> On 7/8/25 3:17 PM, Babu Moger wrote:
>>>> When the "mbm_event" counter assignment mode is enabled, a hardware counter
>>>> must be assigned to read the event.
>>>>
>>>> Report 'Unassigned' in case the user attempts to read the event without
>>>> assigning a hardware counter.
>>>>
>>>> Signed-off-by: Babu Moger <babu.moger@....com>
>>>> ---
>>>
>>>
>>>
>>>> ---
>>>>   Documentation/filesystems/resctrl.rst | 8 ++++++++
>>>>   fs/resctrl/ctrlmondata.c              | 6 ++++++
>>>>   2 files changed, 14 insertions(+)
>>>>
>>>> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
>>>> index 446736dbd97f..4f5eb5bbd4b5 100644
>>>> --- a/Documentation/filesystems/resctrl.rst
>>>> +++ b/Documentation/filesystems/resctrl.rst
>>>> @@ -434,6 +434,14 @@ When monitoring is enabled all MON groups will also contain:
>>>>   	for the L3 cache they occupy). These are named "mon_sub_L3_YY"
>>>>   	where "YY" is the node number.
>>>>   
>>>> +	The "mbm_event" counter assignment mode offers "num_mbm_cntrs" number of
>>>> +	counters and allows users to assign counters to mon_hw_id, event pairs
>>>> +	enabling bandwidth monitoring for as long as the counter remains assigned.
>>>> +	The hardware will continue tracking the assigned counter until the user
>>>> +	manually unassigns it, ensuring that event data is not reset during this
>>>> +	period. An MBM event returns 'Unassigned' when the event does not have
>>>> +	a hardware counter assigned.
>>>
>>> Most of this duplicates the "mbm_event" description added in patch #10. It should just
>>> be sufficient to mention that this applies to "mbm_event" counter assignment mode
>>> and then user can look up the main description in the doc.
>>>
>>> The last sentence is related to this section and need an update to reflect behavior
>>> when a CTRL_MON event is read and it or some of the MON groups do not have
>>> counters assigned. The paragraph that precedes this does describe how the sum
>>> works so this can tie into that.
>>
>> Just added following text.
>>
>> When the 'mbm_event' counter assignment mode is enabled, reading
> 
> Not sure how this will turn out ... if I understand correctly it follows a
> paragraph that already starts with "The "mbm_event" counter assignment mode offers ..."
> so there seems to be some redundancy.

There is no redundant text now. . Users can look up about "mbm_event" 
from "mbm_assign_mode". Here is the complete diff.

diff --git a/Documentation/filesystems/resctrl.rst 
b/Documentation/filesystems/resctrl.rst
index 446736dbd97f..01c33f62ce74 100644
--- a/Documentation/filesystems/resctrl.rst
+++ b/Documentation/filesystems/resctrl.rst
@@ -434,6 +434,12 @@ When monitoring is enabled all MON groups will also 
contain:
         for the L3 cache they occupy). These are named "mon_sub_L3_YY"
         where "YY" is the node number.

+       When the 'mbm_event' counter assignment mode is enabled, reading
+       an MBM event of a MON group returns 'Unassigned' if no hardware
+       counter is assigned to it. For CTRL_MON groups, 'Unassigned' is
+       returned if none of the events in the CTRL_MON group or its
+       associated MON groups have assigned counters.
+
  "mon_hw_id":
         Available only with debug option. The identifier used by hardware
         for the monitor group. On x86 this is the RMID.



>> an MBM event returns 'Unassigned' if no hardware counter is assigned
> 
> How about "reading an MBM event" -> "reading an MBM of a MON group" to
> distinguish it from the text about CTRL_MON group that follows it?
> 
>> to it. For CTRL_MON groups, 'Unassigned' is returned if none of the
>> events in the CTRL_MON group or its associated MON groups have assigned
>> counters.
>>
> 
> Reinette
>