Re: [PATCH v3 5/6] fs/resctrl: Do not invoke smp_processor_id() in preemptible context

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

Hi Chenyu,

On 6/8/26 4:26 AM, Chen, Yu C wrote:
> On 6/8/2026 4:36 PM, Thomas Gleixner wrote:
>> On Sat, Jun 06 2026 at 10:38, Chen Yu wrote:
>>> From: Tony Luck <tony.luck@intel.com>
>>>
>>> __l3_mon_event_count() and __l3_mon_event_count_sum() call
>>> smp_processor_id() to obtain the current CPU. However, some
>>> monitor events can be read from any CPU in task context via
>>> mon_event_count(); in that case the calling context is
>>> preemptible and smp_processor_id() triggers a debug warning.
>>
>> Is this new with this MMIO stuff or is this an existing issue? If the
>> latter then this patch should be in front of the series and get a fixes
>> tag. If not the change log should explain it.
>>
> 
> It is an existing issue. I'll adjust the sequence and provide a fixes tag.
> Thanks!


Could you please elaborate how this is an existing issue?

At this point in implementation mon_evt::any_cpu is and can only be false for
all events associated with resource RDT_RESOURCE_L3. This is highlighted by
the existing splat that will be triggered by the
		WARN_ON_ONCE(rr->evt->any_cpu);
that is removed by this patch.

It is this series that makes it possible to read L3 cache occupancy from any CPU.
This is only done in the following patch (6/6) that makes mon_evt::any_cpu for
L3 cache occupancy be conditional on MMIO support enabled by this series.

This patch (5/6) replaces the above mentioned splat with a subtler check since it
is about to become possible for L3 cache occupancy events to be read from any CPU.

I thus do not see this as an existing issue needing fixing but instead a
necessary part of this series that is specifically a preparatory patch for the
final MMIO based event enabling done in patch 6/6.

Reinette