kernel/git/stable/linux.git/fs/resctrl, 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: 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: 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

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