Re: [PATCH v4 4/7] fs,x86/resctrl: Add architecture hooks for every mount/unmount

[Luck, Tony]

On Wed, Apr 22, 2026 at 03:10:59PM -0700, Reinette Chatre wrote:
> Hi Tony,
> 
> On 4/22/26 2:59 PM, Luck, Tony wrote:
> >>> Seems OK. But to make sure that events are accessible, architecture will
> >>> now have to "hold" the pmt_telemetry module regardless of whether
> >>> resctrl file system is mounted.
> >>
> >> Could you please elaborate why this is required? if I understand correctly the
> >> "hold" on the pmt_telemetry module will be done by itself between the
> >> intel_pmt_get_regions_by_feature() and intel_pmt_put_feature_group() calls.
> > 
> > If architecture code runs completely asynchronously to resctrl mount/unmount
> 
> Since there is shared state that is managed via existing locks I do not see
> architecture running completely asynchronously to resctrl mount/unmount.

I think I now have a solution without any new locks in the file system
layer (just a call to resctrl_arch_pre_mount() on every mount and a
call to resctrl_arch_unmount() if the mount fails, and on unmount).

Testing in progress. Cleanup to follow before posting.
> 
> > when would it be safe to call intel_pmt_put_feature_group()?
> 
> I think I am missing something here since I have been assuming all along
> that intel_pmt_put_feature_group() is and will continue to be called from the
> new unmount handler.

Correct.
> 
> Reinette

I'm looking at a more aggressive change to the Kconfig options.

Linus complained[1] that the biggest pain point for new people is getting
the kernel configured. Extra CONFIG options was his prime focus.

So I'm looking at removing CONFIG_X86_CPU_RESCTRL_INTEL_AET completely and
just making intel_aet.c included with CONFIG_X86_CPU_RESCTRL.

It does mean the resctrl will depend on X86_64, killing 32-bit support.
That was discussed before and decision deferred. But there's other 64-bit MMIO
stuff in the pipeline that means we have to make this change sooner or later.

Thoughts on unconditional inclusion and on removing 32-bit support?

-Tony

[1] https://lore.kernel.org/all/CAHk-=whigg3hvOy7c1j1MXFy6o6CHp0g4Tc3Y-MAk+XDssHU0A@xxxxxxxxxxxxxx