Re: [PATCH] gic: increase the arch_timer priority to avoid hardlockup

[Marc Zyngier <maz@kernel.org>]

On Thu, 16 Oct 2025 08:12:23 +0100,
Marc Zyngier <maz@kernel.org> wrote:
> 
> On Thu, 16 Oct 2025 04:47:33 +0100,
> Yifan Wu <wuyifan50@huawei.com> wrote:
> > 
> > From: Qinxin Xia <xiaqinxin@huawei.com>
> > 
> > ----------------------------------------------------------------------
> > 
> > On HIP12, when GIC receives multiple interrupts of the same priority and
> > different types, the interrupts are selected in the following sequence:
> > SPI > LPI > SGI > PPI. This scheduling rule may cause PPI starvation.
> > To prevent starvation from triggering system watchdog hardlockup, the
> > interrupt priority is explicitly increased in the arch_timer driver.
> 
> No. This breaks pseudo NMIs, and is way too invasive. Also, how about
> the other PPIs? Frankly, if your GIC is not able to do some form of
> fair delivery, then it probably isn't fit for purpose.

Thinking about this some more, this is even worse than it looks.

Your GIC is, one way or another, implementing the interrupt classes as
a form of extra (sub-)priority bits, which breaks everything. How do
you want to solve this?  By adding some other hardcoded priority
scheme. That's just as bad as the situation you have now.

What happens if, for example, your have a CPU with a screaming timer
interrupt and that another CPU tries to IPI it? Same problem, just
pushed one level further.

You cannot solve this by just moving from one bad priority scheme to
another. There is simply no priority scheme that can solve this,
because priorities are the exact opposite of fairness, and fairness is
the property we are relying on.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.