Commit Graph

3 Commits

Author SHA1 Message Date
Sachin Sant
1867859184 selftests/powerpc: skip tests for unavailable mitigations.
Mitigation patching test iterates over a set of mitigations irrespective
of whether a certain mitigation is supported/available in the kernel.
This causes following messages on a kernel where some mitigations
are unavailable:

  Spawned threads enabling/disabling mitigations ...
  cat: entry_flush: No such file or directory
  cat: uaccess_flush: No such file or directory
  Waiting for timeout ...
  OK

This patch adds a check for available mitigations in the kernel.

Reported-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Signed-off-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Reviewed-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/163941374362.36967.18016981579099073379.sendpatchset@1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
2021-12-16 21:31:46 +11:00
Russell Currey
cb662608e5 selftests/powerpc: Use date instead of EPOCHSECONDS in mitigation-patching.sh
The EPOCHSECONDS environment variable was added in bash 5.0 (released
2019).  Some distributions of the "stable" and "long-term" variety ship
older versions of bash than this, so swap to using the date command
instead.

"%s" was added to coreutils `date` in 1993 so we should be good, but who
knows, it is a GNU extension and not part of the POSIX spec for `date`.

Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211025102436.19177-1-ruscur@russell.cc
2021-10-27 22:34:02 +11:00
Michael Ellerman
34f7f79827 selftests/powerpc: Add test of mitigation patching
We recently discovered some of our mitigation patching was not safe
against other CPUs running concurrently.

Add a test which enable/disables all mitigations in a tight loop while
also running some stress load. On an unpatched system this almost always
leads to an oops and panic/reboot, but we also check if the kernel
becomes tainted in case we have a non-fatal oops.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210507064225.1556312-1-mpe@ellerman.id.au
2021-05-17 15:27:47 +10:00