Michal Such=C3=A1nek [off-list ref] writes:

On Tue, 01 May 2018 21:11:06 +1000
Michael Ellerman [off-list ref] wrote:

quoted

Michal Such=C3=A1nek [off-list ref] writes:

quoted

On Tue, 24 Apr 2018 14:15:57 +1000
Michael Ellerman [off-list ref] wrote:
=20=20

quoted

From: Michal Suchanek <redacted>
=20
Check what firmware told us and enable/disable the barrier_nospec
as appropriate.
=20
We err on the side of enabling the barrier, as it's no-op on older
systems, see the comment for more detail.
=20
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>=20=20

...

quoted

I am missing the option for the barrier to be disabled by a kernel
commandline argument here.

It does make sense to add a kernel parameter that is checked on
boot to be compatible with other platforms that implement one.=20=20

=20
No other platforms have an option to disable variant 1 mitigations, so
there isn't an existing parameter we can use.

Right, I was looking at an older implementation which turned off both
v1 and v2 with same parameter. In current kernel the v1 mitigation is
not turned off at all.

Ah OK.

quoted

Which is not to say we can't add one, but I wasn't sure if it was
really worth it.

The current thinking is that most performance relevant cases are
covered with array_nospec which has little overhead. The less code we
have for this the better ;-)

Amen to that :)

cheers