linux.git/fs/resctrl/monitor.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: Pass error reading event through to user space

2026-07-23T20:13:49+00:00

Reading of event data is managed through populating a struct rmid_read with
properties of event needing to be read. This data is dispatched to an
appropriate CPU and upon completion any error can be found in rmid_read::err,
or on success the event data will be in rmid_read::val.

rmid_read::err is not updated in the unlikely scenario that the reading of the
event was dispatched to a wrong CPU. If this ever occurs due to a bug in
resctrl the user space read will return "success" but the data reported will
be invalid.

Ensure accurate error reporting so that if there may be an issue with how
resctrl picks a CPU it could be learned with an error to user space instead of
silent failure.

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/6b3c66a49788828bd8c04a6911bd74c91ccd56f3.1782857711.git.reinette.chatre@intel.com

fs/resctrl: Use correct format specifier for printing error pointers

2026-07-20T21:15:15+00:00

Use correct format specifier for error pointer as Coccinelle suggests:

  .../fs/resctrl/monitor.c:148:8-15: WARNING: Consider using %pe to print PTR_ERR()
  .../fs/resctrl/monitor.c:760:9-16: WARNING: Consider using %pe to print PTR_ERR()

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

fs/resctrl: Fix UAF from worker threads when domains are removed

2026-07-13T21:09:38+00:00

The mbm_handle_overflow() and cqm_handle_limbo() workers read event counters
and may sleep while doing so. They are scheduled via delayed_work embedded in
struct rdt_l3_mon_domain. Architecture allocates and frees these domains from
CPU hotplug callbacks under cpus_write_lock(), and the workers acquire
cpus_read_lock() to keep the domain alive across their access.

A use-after-free can occur when a worker is blocked waiting for
cpus_read_lock() while the hotplug core holds cpus_write_lock(): the
architecture frees the rdt_l3_mon_domain that contains the worker's
work_struct. When the worker unblocks, the container_of() it performs on the
embedded work pointer dereferences freed memory.

Drop cpus_read_lock() from the workers and instead drain pending and in-flight
work synchronously before the architecture can free the domain. Since
architecture offlines the domain under cpus_write_lock() after it has been
unlinked from the RCU list and a grace period has elapsed, no new work can be
scheduled. The cancel only needs to wait out existing work. Drop
rdtgroup_mutex during CPU offline around cancel_delayed_work_sync() so that
a worker waiting on the mutex can complete before re-pinning the work on
a different CPU.

When offlining a CPU the architecture may iterate over resources in any order.
For example, the MBA control domain may be offlined before or after
a corresponding L3 monitor domain. Ensure that resctrl fs cancels the workers
no matter what order the architecture offlines the domains.

Fixes: 24247aeeabe9 ("x86/intel_rdt/cqm: Improve limbo list processing")
Closes: https://sashiko.dev/#/patchset/20260429184858.36423-1-tony.luck%40intel.com # [1]
Reported-by: Sashiko
Co-developed-by: Tony Luck
Signed-off-by: Tony Luck
Signed-off-by: Reinette Chatre
Signed-off-by: Borislav Petkov (AMD)
Link: https://patch.msgid.link/3f0e0752deb3421606dfc4600f0ab3a4ae098cd7.1783963505.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

x86,fs/resctrl: Prevent out-of-bounds access while offlining CPU when SNC enabled

2026-07-01T20:15:02+00:00

The architecture updates the cpu_mask in a domain's header to track which
online CPUs are associated with the domain. When this mask becomes empty
the architecture initiates offline of the domain that includes calling
on resctrl fs to offline the domain. If it is a monitoring domain in
which LLC occupancy is tracked resctrl fs forces the limbo handler to
clear all busy RMID state associated with the domain.

The limbo handler always reads the current event value associated with a
busy RMID irrespective of it being checked as part of regular "is it still
busy" check or whether it will be forced released anyway. When reading an
RMID on a system with SNC enabled the "logical RMID" is converted to the
"physical RMID" and this conversion requires the NUMA node ID of the
resctrl monitoring domain that is in turn determined by querying the NUMA
node ID of any CPU belonging to the monitoring domain.

When the monitoring domain is going offline its cpu_mask is empty causing
the NUMA node ID query via cpu_to_node() to be done with "nr_cpu_ids" as
argument resulting in an out-of-bounds access.

Refactor the limbo handler to skip reading the RMID when the RMID will
just be forced to no longer be dirty in the domain anyway. Add a safety
check to the architecture's RMID reader to protect against this scenario.

Fixes: e13db55b5a0d ("x86/resctrl: Introduce snc_nodes_per_l3_cache")
Closes: https://sashiko.dev/#/patchset/cover.1780456704.git.reinette.chatre%40intel.com?part=9
Reported-by: Sashiko 
Signed-off-by: Reinette Chatre 
Signed-off-by: Borislav Petkov (AMD) 
Cc: 
Link: https://patch.msgid.link/16137433df42f85013b2f7a53626795cbd6637b9.1781029125.git.reinette.chatre@intel.com

fs/resctrl: Continue counter allocation after failure

2026-05-08T10:07:43+00:00

In mbm_event mode, with mbm_assign_on_mkdir set to 1, when a user creates a
new CTRL_MON or MON group resctrl attempts to allocate counters for each of
the supported MBM events on each resctrl domain. As counters are limited,
such allocation may fail and when it does counter allocations for the
remaining domains are skipped even if the domains have available counters.

Because of that, the user needs to view the resource group'smbm_L3_assignments
file to get an accurate view of counter assignment in a new resource group and
then manually create counters in the skipped domains with available counters.

Writes to mbm_L3_assignments using the wildcard format, :*=e, also skip
counter allocation in other domains after a counter allocation failure.

When handling a request to create counters in all domains it is unnecessary
for a counter allocation in one domain to prevent counter allocation in
other domains. Always attempt to allocate all the counters requested.

  [ bp: Massage commit message. ]

Signed-off-by: Ben Horgan 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Babu Moger 
Reviewed-by: Reinette Chatre 
Tested-by: Babu Moger 
Link: https://lore.kernel.org/20260506082855.3694761-1-ben.horgan@arm.com

fs/resctrl: Add monitor property 'mbm_cntr_assign_fixed'

2026-05-07T14:29:14+00:00

Commit

  3b497c3f4f04 ("fs/resctrl: Introduce the interface to display monitoring modes")

introduced CONFIG_RESCTRL_ASSIGN_FIXED but left adding the Kconfig
entry until it was necessary. The counter assignment mode is fixed in
MPAM, even when there are assignable counters, and so addressing this
is needed to support MPAM.

To avoid the burden of another Kconfig entry, replace
CONFIG_RESCTRL_ASSIGN_FIXED with a new property in 'struct resctrl_mon',
'mbm_cntr_assign_fixed' to be set by the architecture.

Do not request the architecture to change the counter assignment mode if it
does not support doing so. Provide insight to user space about why such a
request fails.

Signed-off-by: Ben Horgan 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Babu Moger 
Reviewed-by: Reinette Chatre 
Tested-by: Babu Moger 
Link: https://lore.kernel.org/20260506082855.3694761-1-ben.horgan@arm.com