Re: [PATCH] irqchip/gic-v4: Don't allow a VMOVP on a dying VPE

[Marc Zyngier <maz@kernel.org>]

On Wed, 02 Oct 2024 23:17:02 +0100,
Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> On Wed, Oct 02 2024 at 21:49, Marc Zyngier wrote:
> > Kunkun Jiang reports that there is a small window of opportunity for
> > userspace to force a change of affinity for a VPE while the VPE has
> > already been unmapped, but the corresponding doorbell interrupt still
> > visible in /proc/irq/.
> >
> > Plug the race by checking the value of vmapp_count, which tracks whether
> > the VPE is mapped ot not, and returning an error in this case.
> >
> > This involves making vmapp_count common to both GICv4.1 and its v4.0
> > ancestor.
> >
> > Reported-by: Kunkun Jiang <jiangkunkun@huawei.com>
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > Link: https://lore.kernel.org/r/c182ece6-2ba0-ce4f-3404-dba7a3ab6c52@huawei.com
> 
> I assume this wants a Fixes: tag and a cc: stable, no?

Unclear.

While this is clearly a bug, the architectural effects are not fatal,
and nothing goes really wrong. However, some implementations are
reporting this as a RAS error. That's a bit silly, because this isn't
indicative of HW rotting away, and only a sure way to shoot yourself
in the foot. That's the real bug IMO.

So if these people are really hung up on having this addressed in
prehistoric kernels, we can always add:

Fixes: 64edfaa9a234 ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP")

which points to the commit that implements the infrastructure we're
relying on. GICv4.0, which predates the above by at least a couple of
years is also affected, but nobody really cares about that.

Thanks,

	M.

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