Re: [PATCH v12 00/25] Allow AET to use PMT as loadable module

["Luck, Tony" <tony.luck@intel.com>]

On Thu, Sep 17, 2026 at 09:32:58AM -0700, Luck, Tony wrote:
>     Does dropping ep_lock here create a race condition?
>     While ep_lock is dropped, stale endpoints still remain in the global
>     telem_array list. A concurrent resctrl mount could invoke
>     intel_pmt_get_regions_by_feature(), acquire the lock, and cache pointers to
>     the MMIO resources of the devices currently being removed.
>     When pmt_telem_remove() resumes and re-acquires the lock, it unmaps those
>     regions. Won't the concurrent reader be left with validly cached but unmapped
>     memory pointers, leading to a kernel panic when dereferenced by AET?
> 
> This is an existing issue in the pmt_telemetry driver. Scenario is a
> race between a resctrl mount and an unbind of a device. The unbind gets
> to pmt_telem_remove() but loses the race to acquire ep_lock to the mount
> code calling intel_pmt_get_regions_by_feature(). All devices report
> valid MMIO addresses and ep_lock is released then pmt_telem_remove()
> invalidates the MMIO mappings for the device being unbound/removed.
> 
> Perhaps the telemetry driver should prevent removal of devices for the
> interval from intel_pmt_get_regions_by_feature() to intel_pmt_put_feature_group()?
> 
> Can it do that?

It looks like I can avoid making this worse if I add a new log "aet_mmio"lock"
and use that to protect against invalidation of the MMIO virtual
pointers. Then I don't need to drop and reacquire ep_lock.

-Tony