Re: [PATCH v7 10/14] platform/x86/intel/pmt: Register enumeration functions with resctrl

[Luck, Tony]

On Mon, Jun 08, 2026 at 04:22:27PM -0700, Reinette Chatre wrote:
> Hi Tony,
> 
> On 6/1/26 12:56 PM, Tony Luck wrote:
> > INTEL_PMT_TELEMETRY is a loadable module, but resctrl is built-in and cannot
> > call PMT functions directly.  Register the telemetry enumeration function
> > pointers at pmt_telemetry module init, and unregister them at module exit.
> 
> To ensure intel_pmt_get_regions_by_feature() has access to complete data, could
> it be more accurate to register at the end of PMT's .probe() and similarly
> unregister during .remove()?

I agreed with this. But on further reflection I'm going to dissent.

There are multiple devices (at least one per socket). So .probe() is
called for each. Registering with resctrl at the end of .probe() sets
up for a race with a mount of the resctrl file system:

modprobe				mount
.init()
 auxiliary_driver_register()
  .probe() for socket 0 device		rdt_get_tree()
    intel_aet_register_enumeration()	  resctrl_arch_pre_mount()
      mutex_lock(aet_register_lock)	    intel_aet_pre_mount()
	get_feature = get;		      mutex_lock(aet_register_lock)
	...					... blocks ...
      mutex_unlock(aet_register_lock)
						... runs ...
   .probe() for socket 1 device			Does enumeration with socket 0 complete
						but races with socket 1 .probe()

I may keep the unregister call in the .remove() because as soon as the first
device goes away, resctrl can't usefully run. So it seems a good idea to
handle that right away.

I will provide details on the reason for the asymmetric .init() vs. .remove()
in the commit comment (and in code).

Ok?

-Tony