Re: [PATCH 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems

From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>, info@kernelci.org
Cc: Mark Rutland <mark.rutland@arm.com>,
	'Linux Samsung SOC' <linux-samsung-soc@vger.kernel.org>,
	Julien Thierry <julien.thierry@arm.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Morten Rasmussen <Morten.Rasmussen@arm.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	Qais Yousef <Qais.Yousef@arm.com>
Subject: Re: [PATCH 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems
Date: Wed, 31 Oct 2018 16:21:30 +0100	[thread overview]
Message-ID: <99a5f366-4d96-1069-0638-4e036e57afc8@samsung.com> (raw)
In-Reply-To: <20181030105017.GK30658@n2100.armlinux.org.uk>

Hi Russell,

On 2018-10-30 11:50, Russell King - ARM Linux wrote:
> On Fri, Oct 05, 2018 at 10:46:19AM +0100, Russell King - ARM Linux wrote:
>> On Fri, Oct 05, 2018 at 11:09:40AM +0200, Marek Szyprowski wrote:
>>> This patch causes lots of kernel 'BUG' messages on all Samsung Exynos
>>> boards.  It started to appear since it has been merged to linux-next
>>> on 20181002.  I wonder if this issue is Exynos specific or there are
>>> some patches missing in linux-next, which should fix those 'BUGS'.
>>> If this is Exynos specific, please let us know what should be changed
>>> in Exynos platform code to avoid this issue.
>> Thanks for the report.
>>
>> It looks like my solution for big.Little isn't possible... back to
>> the drawing board, and big.Little will have to remain vulnerable to
>> Spectre for another release cycle.
> I've pushed out a new version in my build branch for the autobuilders
> to chew on, but I've little confidence in validating that the problem
> is fixed because the boot results are completely unreliable.
>
> It really doesn't help that kernelci.org flags boot logs as "green"
> and "successful" when they contain such stuff as:
>
> 01:08:40.181846  [    9.309984] Unable to handle kernel paging request at virtual address e7fddef0
>
> which is the kernel hitting a BUG() - for the full log, see:
>
> https://storage.kernelci.org/rmk/to-build/v4.16-38-g9fa10446d304/arm/multi_v7_defconfig/lab-collabora/boot-exynos5800-peach-pi.html
>
> This means the only way to check is to _manually_ go through reading
> each and every boot log - to see if your reported BUG: messages are
> there - no thanks.
>
> If kernelci thinks that a boot which hits a kernel BUG(), but still
> manages to get to a shell prompt is successful, it's giving very
> misleading boot results.  What about a WARN_ON() or an oops that
> still allows it to reach a shell prompt.
>
> Yes, these may be "successful" in so far as reaching the shell prompt,
> but they should at least be flagged for further inspection, not
> effectively marked as "there is nothing wrong here".

I've run my own tests on various Exynos SoC based boards and your
'for-next' branch works fine and don't cause any regressions.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

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