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

[Russell King - ARM Linux <linux@armlinux.org.uk>]

On Wed, Oct 31, 2018 at 04:21:30PM +0100, Marek Szyprowski wrote:
> 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.

The code isn't in for-next because we're in a merge window, and
linux-next is supposed to be stable for the duration of that, only
accepting bug fixes.

It was added briefly to for-next (carefully timed and discussed
with Stephen to ensure it didn't appear in linux-next), to try
and get fuller builder coverage, which is when the above issue was
found.

If you want to test, please use its separate branch, 'spectre'.
Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up