linux.git/fs/resctrl/ctrlmondata.c, branch v7.3-rc1

fs/resctrl: Communicate resource group deleted error via last_cmd_status

2026-07-27T04:28:31+00:00

User space expects last_cmd_status to contain additional information if any
resctrl command fails.

A resctrl command may be blocked on the rdtgroup_mutex waiting for another
command to finish and find that once the mutex is available that the resource
group has since been deleted.

In this scenario the command will fail while last_cmd_status contains either
"ok" if the last_cmd_status buffer is empty or an outdated error from
a previous command failure if last_cmd_status buffer has content.

Include clearing of last_cmd_status buffer as part of rdtgroup_kn_lock_live()
that is used to obtain access and needed locking to a resource group before
attempting a command on the group.

With the last_cmd_status buffer ready, provide an appropriate message to user
space if the resource group has been deleted.

No last_cmd_status treatment is needed for the remaining failure of
rdtgroup_kn_lock_live() encountering a non-existent resource group since that
could only occur during an attempt to obtain a resource group lock on a file
in info/ which is an invalid usage.

Signed-off-by: Reinette Chatre 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Tony Luck 
Tested-by: Babu Moger 
Link: https://patch.msgid.link/9982141ec6f3ec18e0c53d7feabb19651583cf0e.1782857711.git.reinette.chatre@intel.com

fs/resctrl: Change last_cmd_status custom during input parsing

2026-07-26T20:09:41+00:00

A pattern of usage of last_cmd_status was introduced during its enabling in
commit

  c377dcfbee80 ("x86/intel_rdt: Add diagnostics when writing the schemata file")

and since copied throughout resctrl to result in the following custom:

  ..._write()
  {
  	/* Early parsing of input, exit on failure. */

  	/* Obtain rdtgroup_mutex */
  	rdt_last_cmd_clear(); /* Clear last_cmd_status buffer */

  	/*
  	 * Act on user command, failures result in detail
  	 * error message in last_cmd_status buffer via
  	 * rdt_last_cmd_puts()/rdt_last_cmd_printf().
  	 */

  	/* Release rdtgroup_mutex */
  }

If resctrl exits with failure during early parsing of input there are two
possible scenarios:

 - The last_cmd_status buffer is empty and a user's read of
   info/last_cmd_status returns "ok".

 - The last_cmd_status buffer contains details from an earlier ...write()
   failure and a user's read of info/last_cmd_status returns this outdated
   error description.

Writing to a resctrl file is considered a "resctrl command" and the resctrl
documentation states the following about the last_cmd_status file:

  "If the command failed, it will provide more information that can be
   conveyed in the error returns from file operations."

Neither of the current scenarios is correct behavior.

Move early input parsing to be done with rdtgroup_mutex held after the
last_cmd_status buffer is cleared. Let info/last_cmd_status be accurate
when an error is encountered during parsing of user command.

Signed-off-by: Reinette Chatre 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Ben Horgan 
Reviewed-by: Tony Luck 
Tested-by: Babu Moger 
Link: https://patch.msgid.link/c9eba0ef3b9a72b845b4ae02ecd7c098ed8bf06f.1782857711.git.reinette.chatre@intel.com

fs/resctrl: Use accurate and symmetric exit flows

2026-07-25T20:50:02+00:00

During schemata file write handling there is one error exit path labeled
"out" that handles all cleanup and unlocking needed on exit. The staged
configs cleared during an error exit may not have been used at the time
of exit making the clearing of the staged configs unnecessary.

Access the exit code using two labels and only clear the staged
configuration if it was in use at the time of exit. Doing so makes the
code flow obvious and simplifies upcoming changes that improve the
handling of failures during early input parsing.

Signed-off-by: Reinette Chatre 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Tony Luck 
Tested-by: Babu Moger 
Link: https://patch.msgid.link/4cdd79d612dc6d62ccd490e1c31298025d66d385.1782857711.git.reinette.chatre@intel.com

fs/resctrl: Prevent deadlock and use-after-free in info file handlers

2026-07-13T20:06:07+00:00

resctrl provides files under the info/ directory to expose global
configuration and capabilities to userspace. These files are instantiated
statically during filesystem mount and expose data associated with internal
schema structures via kernfs private pointers.

A potential deadlock exists between userspace readers of these info files
and the unmount filesystem teardown process. Reading an info file invokes
kernfs which acquires an active reference, after which the handler typically
attempts to acquire the rdtgroup_mutex.

Concurrently, unmounting the filesystem holds the rdtgroup_mutex and then
attempts to recursively remove the info kernfs nodes involving kernfs_drain()
which blocks until all active references are released.

Another problem exists where info files might be accessed from an outdated
mount if the filesystem is unmounted and remounted during a reader's
execution, leading to a use-after-free when reading the now-deleted private
schema data.

Introduce info_kn_lock() and info_kn_unlock() helpers to coordinate locking
across all info handlers. These helpers mirror similar logic used by resource
group handlers by deliberately breaking the kernfs active protection before
attempting to acquire the rdtgroup_mutex, preventing the deadlock.

To guard against the vulnerability from rapid mount cycling, info_kn_lock()
securely walks the parent lineage of the kernfs node under an RCU section to
confirm the node belongs to the globally active root before permitting the
operation to proceed. Convert all info file handlers to use this helper and
only de-reference the schema after it is determined safe to do so.

Make no attempt to output an error message to last_cmd_status on failure
since failure implies there is no filesystem with which to display the error
to user space.

[ bp: Massage commit message. ]

Closes: https://sashiko.dev/#/patchset/20260515193944.15114-1-tony.luck%40intel.com?part=3
Reported-by: Sashiko
Assisted-by: GitHub_Copilot:gemini-3.1-pro
Signed-off-by: Reinette Chatre
Signed-off-by: Borislav Petkov (AMD)
Reviewed-by: Tony Luck
Link: https://patch.msgid.link/0b5238486bd058704d908d39a75aff2815bd18aa.1783963505.git.reinette.chatre@intel.com

x86,fs/resctrl: Document safe RCU list traversal

2026-07-13T18:35:50+00:00

rdt_resource::ctrl_domains and rdt_resource::mon_domains are RCU lists with
entries added and removed by architecture from CPU hotplug callbacks that are
run with cpus_write_lock() held. These lists can be traversed safely from
resctrl fs by either holding cpus_read_lock() or relying on an RCU read-side
critical section.

resctrl fs traversals of rdt_resource::ctrl_domains and
rdt_resource::mon_domains are done using list_for_each_entry() with
cpus_read_lock() held. Similarly, x86 architecture callbacks use
list_for_each_entry() expecting that resctrl fs makes the call with
cpus_read_lock() held. Inconsistently, a lockdep_assert_cpus_held() precedes
the list_for_each_entry() call with varying distance to document this safe RCU
list traversal.

In preparation for an upcoming traversal of rdt_resource::ctrl_domains that
needs to be done from RCU read-side critical section there is a requirement
for developers to always know exactly in which context the list is being
traversed.

Replace the list_for_each_entry() traversals of RCU list with
list_for_each_entry_rcu() to document that an RCU list is being traversed
while making use of the built-in lockdep expression that additionally
documents that it is cpus_read_lock() that enables the list to be
traversed from non-RCU protection. Only revert to documenting the
safety of traversal using a comment when lockdep does not have needed
visibility in functions called via smp_call*().

The lockdep expression within list_for_each_entry_rcu() depends on
RCU_EXPERT that is not set in a typical debug kernel so keep the existing
lockdep_assert_cpus_held() that is active with CONFIG_LOCKDEP=y found in
typical debug kernel.

Signed-off-by: Reinette Chatre 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://patch.msgid.link/d9373f8da8ffde667740e186ffc96ab69628ac9a.1783963505.git.reinette.chatre@intel.com

fs/resctrl: Add "*" shorthand to set io_alloc CBM for all domains

2026-04-01T22:22:59+00:00

Configuring the io_alloc_cbm interface requires an explicit domain ID for each
cache domain. On systems with high core counts and numerous cache clusters,
this requirement becomes cumbersome for automation and management tasks that
aim to apply a uniform policy.

Introduce a wildcard domain ID selector "*" for the io_alloc_cbm interface.
This enables users to set the same Capacity Bitmask (CBM) across all cache
domains in a single operation.

Signed-off-by: Aaron Tomlin 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Reinette Chatre 
Reviewed-by: Babu Moger 
Tested-by: Babu Moger 
Link: https://patch.msgid.link/20260325001159.447075-3-atomlin@atomlin.com

fs/resctrl: Report invalid domain ID when parsing io_alloc_cbm

2026-04-01T22:11:35+00:00

The last_cmd_status file is intended to report details about the most recent
resctrl filesystem operation, specifically to aid in diagnosing failures.

However, when parsing io_alloc_cbm, if a user provides a domain ID that does
not exist in the resource, the operation fails with -EINVAL without updating
last_cmd_status. This results in inconsistent behaviour where the system call
returns an error, but last_cmd_status misleadingly reports "ok", leaving the
user unaware that the failure was caused by an invalid domain ID.

Write an error message to last_cmd_status when the target domain ID cannot
be found.

Fixes: 28fa2cce7a83 ("fs/resctrl: Introduce interface to modify io_alloc capacity bitmasks")
Suggested-by: Reinette Chatre 
Signed-off-by: Aaron Tomlin 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Reinette Chatre 
Reviewed-by: Babu Moger 
Tested-by: Babu Moger 
Link: https://patch.msgid.link/20260325001159.447075-2-atomlin@atomlin.com

fs/resctrl: Emphasize that L3 monitoring resource is required for summing domains

2026-01-09T15:37:07+00:00

The feature to sum event data across multiple domains supports systems with
Sub-NUMA Cluster (SNC) mode enabled. The top-level monitoring files in each
"mon_L3_XX" directory provide the sum of data across all SNC nodes sharing an
L3 cache instance while the "mon_sub_L3_YY" sub-directories provide the event
data of the individual nodes.

SNC is only associated with the L3 resource and domains and as a result the
flow handling the sum of event data implicitly assumes it is working with
the L3 resource and domains.

Reading of telemetry events does not require to sum event data so this feature
can remain dedicated to SNC and keep the implicit assumption of working with
the L3 resource and domains.

Add a WARN to where the implicit assumption of working with the L3 resource
is made and add comments on how the structure controlling the event sum
feature is used.

Suggested-by: Reinette Chatre 
Signed-off-by: Tony Luck 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Reinette Chatre 
Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com

x86,fs/resctrl: Support binary fixed point event counters

2026-01-05T15:10:41+00:00

resctrl assumes that all monitor events can be displayed as unsigned decimal
integers.

Hardware architecture counters may provide some telemetry events with greater
precision where the event is not a simple count, but is a measurement of some
sort (e.g. Joules for energy consumed).

Add a new argument to resctrl_enable_mon_event() for architecture code to
inform the file system that the value for a counter is a fixed-point value
with a specific number of binary places.

Only allow architecture to use floating point format on events that the file
system has marked with mon_evt::is_floating_point which reflects the contract
with user space on how the event values are displayed.

Display fixed point values with values rounded to ceil(binary_bits * log10(2))
decimal places. Special case for zero binary bits to print "{value}.0".

Signed-off-by: Tony Luck 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Reinette Chatre 
Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com

x86,fs/resctrl: Handle events that can be read from any CPU

2026-01-05T14:38:07+00:00

resctrl assumes that monitor events can only be read from a CPU in the
cpumask_t set of each domain.  This is true for x86 events accessed with an
MSR interface, but may not be true for other access methods such as MMIO.

Introduce and use flag mon_evt::any_cpu, settable by architecture, that
indicates there are no restrictions on which CPU can read that event.  This
flag is not supported by the L3 event reading that requires to be run on a CPU
that belongs to the L3 domain of the event being read.

Signed-off-by: Tony Luck 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Reinette Chatre 
Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com