[PATCH 4/5] arm_mpam: prevent MPAM-Fb accesses inside IRQ handler

[Andre Przywara]

Hi Niyas,

thanks for the reply!

On 5/18/26 12:57, Niyas Sait wrote:
> Hi Andre,
> 
> On Wed, Apr 29, 2026 at 04:13:38PM +0200, Andre Przywara wrote:
> 
>> This error report relies on reading the MSC's error status register
>> (ESR) in the IRQ handler, which is not possible for MPAM-Fb based
>> MSC accesses, since they involve mailbox routines that might sleep.
> 
> I think there are a few other places where we may still end up invoking
> the MPAM-Fb path from atomic/IRQ context.
> 
> For example, _msmon_read() uses smp_call_function_any(), which runs
> __ris_msmon_read() in callback/atomic context

Ah, good point, I thought that the running CPU always being in the mask 
would avoid the IPI - and it does, but it drops the code into atomic 
context anyway, courtesy of disabling preemption when calling get_cpu().
So I just avoid that by checking the interface type and just calling 
__ris_msmon_read() directly for PCC. Maybe there is a smarter solution 
to this, but that seems simple enough.
Will be part of v2.

Many thanks for finding this!

Cheers,
Andre

> 
> static int _msmon_read(struct mpam_component *comp, struct mon_read *arg)
> {
>      ...
>      err = smp_call_function_any(&msc->accessibility,
>                      __ris_msmon_read, arg,
>                      true);
>      ...
> }
> 
> For MPAM-Fb, I think we could potentially avoid the smp_call_function_any() path entirely
> and invoke directly from the current CPU. Since PCC accesses are effectively CPU agnostic,
> I think that should be fine for the MPAM-Fb case.
> 
> Thanks,
> Niyas