On Tue, 23 Mar 2021 at 04:10, Ian Rogers irogers@google.com wrote:
On Mon, Mar 22, 2021 at 6:24 AM Marco Elver elver@google.com wrote:
On Wed, Mar 10, 2021 at 11:41AM +0100, Marco Elver wrote:
Add kselftest to test that remove_on_exec removes inherited events from child tasks.
Signed-off-by: Marco Elver elver@google.com
To make compatible with more recent libc, we'll need to fixup the tests with the below.
Also, I've seen that tools/perf/tests exists, however it seems to be primarily about perf-tool related tests. Is this correct?
I'd propose to keep these purely kernel ABI related tests separate, and that way we can also make use of the kselftests framework which will also integrate into various CI systems such as kernelci.org.
Perhaps there is a way to have both? Having the perf tool spot an errant kernel feels like a feature. There are also tools/lib/perf/tests and Vince Weaver's tests [1]. It is possible to run standalone tests from within perf test by having them be executed by a shell test.
Thanks for the pointers. Sure, I'd support more additional tests.
But I had another look and it seems the tests in tools/{perf,lib/perf}/tests do focus on perf-tool or the library respectively, so adding kernel ABI tests there feels wrong. (If perf-tool somehow finds use for sigtrap, or remove_on_exec, then having a perf-tool specific test for those would make sense again.)
The tests at [1] do seem relevant, and its test strategy seems more extensive, including testing older kernels. Unfortunately it is out-of-tree, but that's probably because it was started before kselftest came into existence. But there are probably things that [1] contains that are not appropriate in-tree.
It's all a bit confusing.
Going forward, if you insist on tests being also added to [1], we can perhaps mirror some of the kselftest tests there. There's also a logistical problem with the tests added here, because the tests require an up-to-date siginfo_t, and they use the kernel's <asm/siginfo.h> with some trickery. Until libc's siginfo_t is updated, it probably doesn't make sense to add these tests to [1].
The other question is, would it be possible to also copy some of the tests in [1] and convert to kselftest, so that they live in-tree and are tested regularly (CI, ...)?
Because I'd much prefer in-tree tests with little boilerplate, that are structured with parsable output; in the kernel we have the kselftest framework for tests with a user space component, and KUnit for pure in-kernel tests.
Thanks, -- Marco
Thanks, Ian
[...]