From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Marek Szyprowski <m.szyprowski@samsung.com>, 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: Tue, 30 Oct 2018 10:50:18 +0000 [thread overview]
Message-ID: <20181030105017.GK30658@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20181005094618.GG30658@n2100.armlinux.org.uk>
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".
--
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
WARNING: multiple messages have this Message-ID (diff)
From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems
Date: Tue, 30 Oct 2018 10:50:18 +0000 [thread overview]
Message-ID: <20181030105017.GK30658@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20181005094618.GG30658@n2100.armlinux.org.uk>
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".
--
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
next prev parent reply other threads:[~2018-10-30 10:50 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-19 9:48 [PATCH 0/5] Spectre big.Little updates Russell King - ARM Linux
2018-09-19 9:48 ` [PATCH 1/5] ARM: make lookup_processor_type() non-__init Russell King
2018-09-20 9:07 ` Julien Thierry
2018-09-19 9:48 ` [PATCH 2/5] ARM: split out processor lookup Russell King
2018-09-20 9:05 ` Julien Thierry
2018-09-19 9:49 ` [PATCH 3/5] ARM: clean up per-processor check_bugs method call Russell King
2018-09-20 9:06 ` Julien Thierry
2018-09-19 9:49 ` [PATCH 4/5] ARM: add PROC_VTABLE macro Russell King
2018-09-20 9:07 ` Julien Thierry
2018-09-19 9:49 ` [PATCH 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems Russell King
2018-09-20 9:04 ` Julien Thierry
2018-09-20 9:21 ` Russell King - ARM Linux
2018-09-20 9:28 ` Julien Thierry
2018-10-05 9:09 ` Marek Szyprowski
2018-10-05 9:09 ` Marek Szyprowski
2018-10-05 9:35 ` Krzysztof Kozlowski
2018-10-05 9:35 ` Krzysztof Kozlowski
2018-10-05 9:46 ` Russell King - ARM Linux
2018-10-05 9:46 ` Russell King - ARM Linux
2018-10-30 10:50 ` Russell King - ARM Linux [this message]
2018-10-30 10:50 ` Russell King - ARM Linux
2018-10-31 15:21 ` Marek Szyprowski
2018-10-31 15:21 ` Marek Szyprowski
2018-10-31 18:12 ` Russell King - ARM Linux
2018-10-31 18:12 ` Russell King - ARM Linux
2018-11-02 17:17 ` Kevin Hilman
2018-11-02 17:17 ` Kevin Hilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181030105017.GK30658@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=Morten.Rasmussen@arm.com \
--cc=Qais.Yousef@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=info@kernelci.org \
--cc=julien.thierry@arm.com \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.