On Mon, Sep 02, 2019 at 12:29:21pm +0100, Cristian Marussi wrote:
Hi
this patchset aims to add the initial arch-specific arm64 support to kselftest starting with signals-related test-cases. A common internal test-case layout is proposed which then it is anyway wired-up to the toplevel kselftest Makefile, so that it should be possible at the end to run it on an arm64 target in the usual way with KSFT.
BTW, it's helpful to state the base branch / commit as clearly as possible near the top of the cover letter, say,
--8<--
This series is based on arm64/for-next/core [1] commit 9ce1263033cd ("selftests, arm64: add a selftest for passing tagged pointers to kernel")
[1] git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
-->8--
This is particularly important if you expect the maintainer to pick up the patches.
You don't need to reference a specific commit unless there's a significant chance of conflicts if the wrong commit is used, but it can help provide a clue as to why you're basing on this alternate branch.
~/linux# make TARGETS=arm64 kselftest
New KSFT arm64 testcases live inside tools/testing/selftests/arm64 grouped by family inside subdirectories: arm64/signal is the first family proposed with this series. This series converts also to this subdirectory scheme the pre-existing (already queued on arm64/for-next/core) KSFT arm64 tags tests, moving them into arm64/tags.
Thanks
Cristian
Notes:
further details in the included READMEs
more tests still to be written (current strategy is going through the related Kernel signal-handling code and write a test for each possible and sensible code-path) A few ideas for more TODO testcases:
- fake_sigreturn_unmapped_sp: SP into unmapped addrs
- fake_sigreturn_kernelspace_sp: SP into kernel addrs
- fake_sigreturn_sve_bad_extra_context: SVE extra context badly formed
- mangle_sve_invalid_extra_context: SVE extra_context invalid
SVE signal testcases and special handling will be part of an additional patch still to be released
What's your approach to checking that the test failure paths work?
We could either hack the kernel or the tests to provoke "fake" failures, and I don't think it's necessary to test everything in this way, providing we have confidence that the test strategy and framework works in general.
[...]
Cheers ---Dave