Re: [EXT] Re: [PATCH] clocksource: Add Marvell Errata-38627 workaround

From: Marc Zyngier <maz@kernel.org>
To: Bharat Bhushan <bbhushan2@marvell.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"will@kernel.org" <will@kernel.org>,
	"daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>,
	"konrad.dybcio@somainline.org" <konrad.dybcio@somainline.org>,
	"saiprakash.ranjan@codeaurora.org"
	<saiprakash.ranjan@codeaurora.org>,
	"robh@kernel.org" <robh@kernel.org>,
	"marcan@marcan.st" <marcan@marcan.st>,
	"suzuki.poulose@arm.com" <suzuki.poulose@arm.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linu Cherian <lcherian@marvell.com>,
	Sunil Kovvuri Goutham <sgoutham@marvell.com>
Subject: Re: [EXT] Re: [PATCH] clocksource: Add Marvell Errata-38627 workaround
Date: Tue, 13 Jul 2021 16:38:56 +0100	[thread overview]
Message-ID: <87o8b66x67.wl-maz@kernel.org> (raw)
In-Reply-To: <CO6PR18MB4465C85A872D7CE4138EBF8FE3149@CO6PR18MB4465.namprd18.prod.outlook.com>

Hi Bharat,

On Tue, 13 Jul 2021 03:40:22 +0100,
Bharat Bhushan <bbhushan2@marvell.com> wrote:
> 
> Hi Mark,
>
> -----Original Message-----
> From: Mark Rutland <mark.rutland@arm.com>

[...]

> > From your description so far, this doesn't sound like it is
> > specific to the timer interrupt. Is it possible for a different
> > interrupt to trigger this, e.g:
> > 
> > * Can the same happen with another PPI, e.g. the PMU interrupt if that
> >   gets de-asserted, or there's a race with DAIF.I?
> > 
> > * Can the same happen with an SGI, e.g. if one CPU asserts then
> >   de-asserts an SGI targetting another CPU, or there's a race with
> >   DAIF.I?
> > 
> > * Can the same happen with an SPI, e.g. if a device asserts then
> >   de-asserts its IRQ line, or there's a race with DAIF.I?
> 
> No issue with edge triggered, but this can happen with any level
> sensitive interrupt.

So let's say CPU0 is targeted by a level-triggered SPI, and right when
the interrupt is reaching the CPU interface, CPU1 disables this
interrupt, which gets recalled, and CPU0 never takes the interrupt.
Bug hits again. Drivers do that.

I actually suspect that an edge-triggered interrupt would result in
the same issue, unless your GIC implementation isn't able to perform a
recall on edge interrupts.

I don't understand why you are only considering the timer here. Any
interrupt can trigger this, and if there is going to be a workaround,
it will need to be robust against all interrupts being retired, no
matter what device triggers it.

And given that the OoO nature of the machine leaks non architectural
state, potentially belonging to a different security context, this
isn't something that should be taken lightly.

	M.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel