Re: [PATCH v5 00/10] x86,fs/resctrl: Improve resctrl quality and consistency

[Reinette Chatre <reinette.chatre@intel.com>]

Dear x86 maintainers,

Could you please consider this series for inclusion? It applies cleanly on top
of x86/cache with HEAD at
	 2566b5cd6a27 ("fs/resctrl: Fix UAF from worker threads when domains are removed")

There is another resctrl series ("x86,fs/resctrl,arm_mpam: Factor MBA parse-time conversion
to be per-arch") also ready for your consideration. There are no conflicts between it and
this series, they can be considered in any order.

Thank you very much.

Reinette

[1] https://lore.kernel.org/lkml/20260709093111.367851-1-ben.horgan@arm.com/

On 6/30/26 9:27 PM, Reinette Chatre wrote:
> Applies on top of v7.2-rc1 + v5 of "x86,fs/resctrl: Fix long-standing issues":
>   https://lore.kernel.org/lkml/cover.1781029125.git.reinette.chatre@intel.com/
> 
> Changes since v4:
> - v4: https://lore.kernel.org/lkml/cover.1777419024.git.reinette.chatre@intel.com/
> - Rebased on top of V5 "x86,fs/resctrl: Fix long-standing issues":
>   https://lore.kernel.org/lkml/cover.1781029125.git.reinette.chatre@intel.com/
>   A significant change in that series is the addition of
>   info_kn_lock()/info_kn_unlock() helpers to the info file handlers. With
>   the addition of locking to the max_threshold_occ_write() in that series
>   it seemed appropriate to re-order the last_cmd_status handling in
>   max_threshold_occ_write() to be after the change to last_cmd_status
>   custom to contain max_threshold_occ_write() changes to one patch.
> - Add resctrl filename to new error messages to disambiguate the various
>   "Invalid input" messages. (Tony)
> - Add Tony's Reviewed-by tag to all patches.
> 
> Changes since v3:
> - v3: https://lore.kernel.org/lkml/cover.1775576382.git.reinette.chatre@intel.com/
> - Rebased on v7.1-rc1.
> - Drop "MAINTAINERS: Update resctrl entry" and "fs/resctrl: Add missing return
>   value descriptions" that can be found in v7.1-rc1.
> - Drop "fs/resctrl: Avoid "may be used uninitialized" warning" that just does unnecessary
>   work to appease compiler warning that is disabled by default. (Boris)
> - Use pr_warn() instead of WARN_ON() in "x86/resctrl: Protect against bad
>   shift".
> 
> Changes since v2:
> - v2: https://lore.kernel.org/lkml/cover.1774043709.git.reinette.chatre@intel.com/
> - Rebased on top of tip/master with pending resctrl selftest changes,
>   https://lore.kernel.org/lkml/cover.1775266384.git.reinette.chatre@intel.com/,
>   applied on top to support testing with latest kernel that has pending resctrl
>   changes merged.
> - Drop "fs/resctrl: Use stricter checks on input to cpus/cpus_list file"
>   that ended up being too strict and removed one use case. (Chris)
> - max_threshold_occ_write() switch to guard(). (Chenyu)
> - Add more detail to one return value description.
> - Add tags.
> - No opinions so far on needing to update last_cmd_status on success of all read
>   commands. At this time last_cmd_status will continue to return previous
>   failure message (if any) after a read command accessing static data succeeds.
> 
> Changes since v1:
> - v1: https://lore.kernel.org/lkml/cover.1772476561.git.reinette.chatre@intel.com/
> - To simplify tracking, include patch to MAINTAINERS submitted separately:
>   https://lore.kernel.org/lkml/4274c478922c01f9ceebc805acf991f10a95519f.1771442788.git.reinette.chatre@intel.com/
> - Follow recent upstream changes to add reference to tip tree handbook in
>   MAINTAINERS entry.
> - Use new pattern in resctrl to enable looping over all entries of an enum
>   while making adding new enum entries more clear all while avoiding warnings
>   when compiling with -Wswitch. (Ben)
> - Add another last_cmd_status enhancement that appends "[truncated]" to
>   output of info/last_cmd_status if the backing buffer overflowed.
> - Please see patch changelogs for details of changes.
> - Add tags.
> 
> Hi Everybody,
> 
> This is a collection of resctrl cleanups assembled together for convenience
> and simpler tracking. I'd be happy to split them up if it makes review and/or
> handling easier.
> 
> Summary of changes:
> 
> - Let resctrl pass stricter checks from various tools to provide a cleaner
>   baseline with the goal to promote healthier contributions:
>   - ./tools/docs/kernel-doc -Wall -v <files>
>   - Build with W=12
>   - ./scripts/coccicheck
>   - Static checkers
> 
> - Use accurate and consistent type for all uses of resource ID.
> 
> - In the unlikely scenario that resctrl picked a wrong CPU to read an event
>   from, pass the error through to user space instead of claiming to succeed
>   and returning a (wrong) result.
> 
> - Since inception of last_cmd_status feature there have been mismatches
>   between resctrl file operation failures and the contents of
>   info/last_cmd_status. This pattern keeps propagating with each new resctrl
>   feature. Establish a new baseline with a new pattern that ensures
>   info/last_cmd_status contains an accurate failure description that matches
>   the most recent resctrl file operation failure.
> 
> One potential open:
> 
> There remains an inconsistency between resctrl file operations that do/can
> _not_ fail and the contents of info/last_cmd_status. If a resctrl
> file operation fails and an informational error is printed to last_cmd_status
> then a subsequent reading of a resctrl file (specifically most of the files
> found in info/) may succeed while info/last_cmd_status may or may not return
> the error from previous failure.
> 
> Ensuring last_cmd_status is reset on every read carries the cost of taking
> rdtgroup_mutex on several more user space initiated paths and thus increase
> contention on rdtgroup_mutex. I opted to not make this change and instead
> focus this work on ensuring that last_cmd_status is accurate whenever there is
> a failure during any resctrl file operation. Please let me know if you have
> opinions in this regard.
> 
> Update v5: The addition of the info_kn_lock()/info_kn_unlock() helpers to
> info file handlers now means that rdtgroup_mutex is held every time an info
> file is opened. There is thus now less burden to reset last_cmd_status
> buffer on each info file access. Even so, since there has not been any
> opinions in this regard I opted to keep current behavior.
> 
> Any feedback is appreciated.
> 
> Regards,
> 
> Reinette
> 
> Reinette Chatre (10):
>   fs/resctrl: Use correct format specifier for printing error pointers
>   x86/resctrl: Protect against bad shift
>   fs/resctrl: Change pattern used to track number of entries in enum
>   fs/resctrl: Use accurate type for rdt_resource::rid
>   fs/resctrl: Pass error reading event through to user space
>   fs/resctrl: Use accurate and symmetric exit flows
>   fs/resctrl: Change last_cmd_status custom during input parsing
>   fs/resctrl: Add last_cmd_status support for writes to
>     max_threshold_occupancy
>   fs/resctrl: Communicate resource group deleted error via
>     last_cmd_status
>   fs/resctrl: Inform user space when status buffer overflowed
> 
>  arch/x86/kernel/cpu/resctrl/core.c |   6 +-
>  fs/resctrl/ctrlmondata.c           |  71 ++++++++++-------
>  fs/resctrl/monitor.c               |  78 ++++++++++--------
>  fs/resctrl/rdtgroup.c              | 123 +++++++++++++++++------------
>  include/linux/resctrl.h            |  11 +--
>  5 files changed, 173 insertions(+), 116 deletions(-)
>