On Wed, Aug 07, 2024 at 07:39:54PM -0300, Thiago Jung Bauermann wrote:
> Mark Brown <broonie@xxxxxxxxxx> writes:
> > Add a stress test which runs one more process than we have CPUs spinning
> > through a very recursive function with frequent syscalls immediately prior
> Unfortunately, gcs-stress still fails on my FVP setup. I tested on an
> arm64 defconfig with and without THP enabled with, the same results:
Can you please try to investigate why this is happening on your system?
I am unable to reproduce this, for example the actual branch that was
posted gave this:
# selftests: arm64: gcs-stress
# TAP version 13
# 1..9
# # 8 CPUs, 9 GCS threads
# # Will run for 10s
# # Started Thread-8350
# # Started Thread-8351
# # Started Thread-8352
# # Started Thread-8353
# # Started Thread-8354
# # Started Thread-8355
# # Started Thread-8356
# # Started Thread-8357
# # Started Thread-8358
# # Thread-8350: Running
...
# # Sending signals, timeout remaining: 100ms
# # Finishing up...
# # Thread-8351: Terminated by signal 15, no error
# # Thread-8352: Terminated by signal 15, no error
# # Thread-8353: Terminated by signal 15, no error
# # Thread-8354: Terminated by signal 15, no error
# # Thread-8355: Terminated by signal 15, no error
# # Thread-8357: Terminated by signal 15, no error
# # Thread-8358: Terminated by signal 15, no error
# ok 1 Thread-8350
# ok 2 Thread-8351
# ok 3 Thread-8352
# ok 4 Thread-8353
# ok 5 Thread-8354
# ok 6 Thread-8355
# ok 7 Thread-8356
# ok 8 Thread-8357
# ok 9 Thread-8358
# # Thread-8356: Terminated by signal 15, no error
# # Thread-8350: Terminated by signal 15, no error
# # Totals: pass:9 fail:0 xfail:0 xpass:0 skip:0 error:0
and Anders also ran the selftests successfully, including with THP
enabled (as noted in the changelog those issues should now be resolved).
THP issues should not have been relevant for this test as it doesn't
fork with GCS enabled.
> # # Thread-4870: Failed to enable GCS
which is printed if a basic PR_SET_SHADOW_STACK_STATUS fails immediately
the program starts executing:
function _start
// Run with GCS
mov x0, PR_SET_SHADOW_STACK_STATUS
mov x1, PR_SHADOW_STACK_ENABLE
mov x2, xzr
mov x3, xzr
mov x4, xzr
mov x5, xzr
mov x8, #__NR_prctl
svc #0
cbz x0, 1f
puts "Failed to enable GCS\n"
b abort
the defines for which all seem up to date (and unlikely to fail in
system or config specific fashions). What happens if you try to execute
the gcs-stress-thread binary directly, does strace show anything
interesting? If you instrument arch_set_shadow_stack_status() in the
kernel does it show anything?
Attachment:
signature.asc
Description: PGP signature
