kernel/git/stable/linux.git/fs/resctrl/rdtgroup.c, branch master

fs/resctrl: Inform user space when status buffer overflowed

2026-07-27T04:40:26+00:00

resctrl fs commands are becoming more powerful with, for example, a user able to use syntax like '*' to make broad configuration changes. Such commands that span multiple domains may result in more than one message printed to the last_cmd_status buffer with more planned. Issue "[truncated]" when displaying the last_cmd_status buffer to communicate if it overflowed. Upon encountering this, user space is expected to combine details about the failure found in info/last_cmd_status with related resctrl files to learn the accurate system state after the command 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/eb3d1aaa41d1f2bf6b1bb26ceafd52f04912121d.1782857711.git.reinette.chatre@intel.com

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: Add last_cmd_status support for writes to max_threshold_occupancy

2026-07-27T04:22:37+00:00

info/last_cmd_status is intended to contain more information if a write to any resctrl file fails. Writes to max_threshold_occupancy did not receive last_cmd_status support during initial last_cmd_status enabling. Add it now. Signed-off-by: Reinette Chatre Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tony Luck Tested-by: Babu Moger Link: https://patch.msgid.link/dfc60cf5324e15612db075b0987bd89c490fbad5.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: 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

fs/resctrl: Prevent use-after-free in rdtgroup_kn_put()

2026-07-13T19:53:21+00:00

A struct rdtgroup is reference counted via rdtgroup::waitcount. Callers that need the structure to remain valid across a sleep (while waiting on acquiring rdtgroup_mutex) take a reference with rdtgroup_kn_get() and release it with rdtgroup_kn_put(). The release path is intended to serve as the fallback freer: if the count drops to zero and the group has already been marked RDT_DELETED, rdtgroup_kn_put() frees the structure. The bulk teardown paths free_all_child_rdtgrp() and rmdir_all_sub() resulting from a resctrl directory remove or resctrl fs unmount act as the primary freer: they hold rdtgroup_mutex and free each rdtgroup whose waitcount is zero, otherwise they set RDT_DELETED and leave the freeing to the last waiter. These two freers race. rdtgroup_kn_put() commits waitcount == 0 with atomic_dec_and_test() outside rdtgroup_mutex, then reads rdtgroup::flags. Between those two operations a concurrent caller of free_all_child_rdtgrp() or rmdir_all_sub() (which holds the mutex) can observe waitcount == 0 via atomic_read(), call rdtgroup_remove(), and kfree() the structure. The subsequent read of rdtgroup::flags in rdtgroup_kn_put() is then a use-after-free, and the structure may even be freed twice if the freed memory happens to satisfy the RDT_DELETED flag check. Replace the bare atomic_dec_and_test() with atomic_dec_and_mutex_lock() so that the decrement-to-zero takes rdtgroup_mutex before the count becomes globally visible. The inspection of rdtgroup::flags then runs under the same mutex held by the bulk freers, making the two paths mutually exclusive. The common case where the count does not reach zero remains lock-free. Defer kernfs_unbreak_active_protection() until after the mutex is dropped since kernfs active protections functionally wrap rdtgroup_mutex. Remove resource group, which in turn drops its kernfs reference, after kernfs protection is restored. [ bp: Split the commit messsages into smaller, easier-parseable paragraphs. ] Fixes: b8511ccc75c0 ("x86/resctrl: Fix use-after-free when deleting resource groups") Closes: https://sashiko.dev/#/patchset/20260515193944.15114-1-tony.luck%40intel.com?part=1 Reported-by: Sashiko Assisted-by: GitHub_Copilot:gemini-3.1-pro Signed-off-by: Reinette Chatre Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Ben Horgan Reviewed-by: Tony Luck Link: https://patch.msgid.link/8d028bbea582dc382a4cc166b235f75bd5901aea.1783963505.git.reinette.chatre@intel.com

fs/resctrl: Fix deadlock on errors during mount

2026-07-13T19:39:20+00:00

rdt_get_tree() acquires rdtgroup_mutex before calling kernfs_get_tree(). If superblock setup fails inside kernfs_get_tree(), the VFS calls .kill_sb() (rdt_kill_sb()) on the same thread before kernfs_get_tree() returns. rdt_kill_sb() unconditionally attempts to acquire rdtgroup_mutex and deadlock occurs. Since mount failure resulting from kernfs_get_tree() already calls the resctrl fs unmount handler (rdt_kill_sb()) let both call the same helper to make it clear both paths perform the same cleanup. Call kernfs_get_tree() outside of locks. If kernfs_get_tree() fails and ctx->kfc.new_sb_created is set, then rdt_kill_sb() has already been called and no further cleanup is needed. kernfs_get_tree() may set ctx->kfc.new_sb_created and then fail to obtain an inode for the new kn, causing the rdt_kill_sb() path to run with one fewer reference than required for the root to remain accessible in kernfs_kill_sb(). Add an extra hold on rdtgroup_default.kn to defend against this scenario and ensure the root can be dereferenced safely from kernfs_kill_sb(). Dropping locks before kernfs_get_tree() creates a window where CPU hotplug callbacks can race with the mount operation. Specifically, an online event observing resctrl_mounted == true could concurrently append directories to the unactivated kernfs tree, allocate mon_data structures, and arm background workers. This concurrency is safe because the mount has not yet returned to the VFS, meaning userspace cannot interact with these transient files. If kernfs_get_tree() subsequently fails, the standard resctrl_unmount() teardown safely manages the concurrent modifications: any dynamically generated kernfs nodes are removed, and the associated memory is freed. Any background workers spawned by the hotplug event will naturally exit without re-arming when they acquire rdtgroup_mutex and observe resctrl_mounted == false. Fixes: 5ff193fbde20 ("x86/intel_rdt: Add basic resctrl filesystem support") 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) Reviewed-by: Ben Horgan Reviewed-by: Chen Yu Link: https://patch.msgid.link/fe701825d7f538a6bbac6732230004050300c93e.1783963505.git.reinette.chatre@intel.com

fs/resctrl: Move functions to avoid forward references in subsequent fixes

2026-07-13T19:26:32+00:00

rdt_get_tree() manages resctrl fs mount and rdt_kill_sb() manages resctrl fs unmount. There is significant overlap between error cleanup during resctrl mount failure and cleanup on resctrl unmount yet the cleanup is not done consistently in these two flows. Pull some cleanup functions before rdt_get_tree() in preparation for a new helper that can be shared between mount and unmount. Signed-off-by: Tony Luck Signed-off-by: Reinette Chatre Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Ben Horgan Link: https://patch.msgid.link/af10101be95679e1d69ce4efc3edf980a6cc37cc.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