Hi, Alexei!
>>>>> On Wed, 27 May 2020 09:48:04 -0700, Alexei Starovoitov wrote:
> On Wed, May 27, 2020 at 12:19 AM Yauheni Kaliuta
> <yauheni.kaliuta(a)redhat.com> wrote:
>>
>> Hi, Alexei!
>>
>> >>>>> On Tue, 26 May 2020 22:37:39 -0700, Alexei Starovoitov wrote:
>>
>> > On Tue, May 26, 2020 at 10:31 PM Yauheni Kaliuta
>> > <yauheni.kaliuta(a)redhat.com> wrote:
>> >>
>> >> Hi, Andrii!
>> >>
>> >> >>>>> On Tue, 26 May 2020 17:19:18 -0700, Andrii Nakryiko wrote:
>> >>
>> >> > On Fri, May 22, 2020 at 1:19 AM Yauheni Kaliuta
>> >> > <yauheni.kaliuta(a)redhat.com> wrote:
>> >> >>
>> >> >> There is difference in depoying static and generated extra resource
>> >> >> files between in/out of tree build and flavors:
>> >> >>
>> >> >> - in case of unflavored out-of-tree build static files are not
>> >> >> available and must be copied as well as both static and generated
>> >> >> files for flavored build.
>> >> >>
>> >> >> So split the rules and variables. The name TRUNNER_EXTRA_GEN_FILES
>> >> >> is chosen in analogy to TEST_GEN_* variants.
>> >> >>
>> >>
>> >> > Can we keep them together but be smarter about what needs to
>> >> > be copied based on source/target directories? I would really
>> >> > like to not blow up all these rules.
>> >>
>> >> I can try, ok, I just find it a bit more clear. But it's good to
>> >> get some input from kselftest about OOT build in general.
>>
>> > I see no value in 'make install' of selftests/bpf
>> > and since it's broken just remove that makefile target.
>>
>> Some CI systems perform testing next stage after building were
>> build tree is not available anymore. So it's in use at the
>> moment.
> such CI systems can do 'cp -r' then
It's a discussion for linux-kselftest@ (added).
At the moment `make install` is generic kselftest functionality
and since bpf is part of that infra it looks a bit strange to
break it intentionally.
--
WBR,
Yauheni Kaliuta
This patchset contains everything needed to integrate KASAN and KUnit.
KUnit will be able to:
(1) Fail tests when an unexpected KASAN error occurs
(2) Pass tests when an expected KASAN error occurs
Convert KASAN tests to KUnit with the exception of copy_user_test
because KUnit is unable to test those.
Add documentation on how to run the KASAN tests with KUnit and what to
expect when running these tests.
This patchset depends on:
- "[PATCH v3 kunit-next 0/2] kunit: extend kunit resources API" [1]
- "[PATCH v3 0/3] Fix some incompatibilites between KASAN and
FORTIFY_SOURCE" [2]
Changes from v6:
- Rebased on top of kselftest/kunit
- Rebased on top of Daniel Axtens' fix for FORTIFY_SOURCE
incompatibilites [2]
- Removed a redundant report_enabled() check.
- Fixed some places with out of date Kconfig names in the
documentation.
Changes from v5:
- Split out the panic_on_warn changes to a separate patch.
- Fix documentation to fewer to the new Kconfig names.
- Fix some changes which were in the wrong patch.
- Rebase on top of kselftest/kunit (currently identical to 5.7-rc1)
Changes from v4:
- KASAN no longer will panic on errors if both panic_on_warn and
kasan_multishot are enabled.
- As a result, the KASAN tests will no-longer disable panic_on_warn.
- This also means panic_on_warn no-longer needs to be exported.
- The use of temporary "kasan_data" variables has been cleaned up
somewhat.
- A potential refcount/resource leak should multiple KASAN errors
appear during an assertion was fixed.
- Some wording changes to the KASAN test Kconfig entries.
Changes from v3:
- KUNIT_SET_KASAN_DATA and KUNIT_DO_EXPECT_KASAN_FAIL have been
combined and included in KUNIT_DO_EXPECT_KASAN_FAIL() instead.
- Reordered logic in kasan_update_kunit_status() in report.c to be
easier to read.
- Added comment to not use the name "kasan_data" for any kunit tests
outside of KUNIT_EXPECT_KASAN_FAIL().
Changes since v2:
- Due to Alan's changes in [1], KUnit can be built as a module.
- The name of the tests that could not be run with KUnit has been
changed to be more generic: test_kasan_module.
- Documentation on how to run the new KASAN tests and what to expect
when running them has been added.
- Some variables and functions are now static.
- Now save/restore panic_on_warn in a similar way to kasan_multi_shot
and renamed the init/exit functions to be more generic to accommodate.
- Due to [3] in kasan_strings, kasan_memchr, and
kasan_memcmp will fail if CONFIG_AMD_MEM_ENCRYPT is enabled so return
early and print message explaining this circumstance.
- Changed preprocessor checks to C checks where applicable.
Changes since v1:
- Make use of Alan Maguire's suggestion to use his patch that allows
static resources for integration instead of adding a new attribute to
the kunit struct
- All KUNIT_EXPECT_KASAN_FAIL statements are local to each test
- The definition of KUNIT_EXPECT_KASAN_FAIL is local to the
test_kasan.c file since it seems this is the only place this will
be used.
- Integration relies on KUnit being builtin
- copy_user_test has been separated into its own file since KUnit
is unable to test these. This can be run as a module just as before,
using CONFIG_TEST_KASAN_USER
- The addition to the current task has been separated into its own
patch as this is a significant enough change to be on its own.
[1] https://lore.kernel.org/linux-kselftest/1585313122-26441-1-git-send-email-a…
[2] https://lkml.org/lkml/2020/4/23/708
[3] https://bugzilla.kernel.org/show_bug.cgi?id=206337
David Gow (1):
mm: kasan: Do not panic if both panic_on_warn and kasan_multishot set
Patricia Alfonso (4):
Add KUnit Struct to Current Task
KUnit: KASAN Integration
KASAN: Port KASAN Tests to KUnit
KASAN: Testing Documentation
Documentation/dev-tools/kasan.rst | 70 +++
include/kunit/test.h | 5 +
include/linux/kasan.h | 6 +
include/linux/sched.h | 4 +
lib/Kconfig.kasan | 18 +-
lib/Makefile | 3 +-
lib/kunit/test.c | 13 +-
lib/test_kasan.c | 688 +++++++++++++-----------------
lib/test_kasan_module.c | 76 ++++
mm/kasan/report.c | 34 +-
10 files changed, 514 insertions(+), 403 deletions(-)
create mode 100644 lib/test_kasan_module.c
--
2.26.2.303.gf8c07b1a785-goog
A recent RFC patch set [1] suggests some additional functionality
may be needed around kunit resources. It seems to require
1. support for resources without allocation
2. support for lookup of such resources
3. support for access to resources across multiple kernel threads
The proposed changes here are designed to address these needs.
The idea is we first generalize the API to support adding
resources with static data; then from there we support named
resources. The latter support is needed because if we are
in a different thread context and only have the "struct kunit *"
to work with, we need a way to identify a resource in lookup.
[1] https://lkml.org/lkml/2020/2/26/1286
Changes since v2:
- moved a few functions relating to resource retrieval in patches
1 and 2 into include/kunit/test.h and defined as "static inline";
this allows built-in consumers to use these functions when KUnit
is built as a module
Changes since v1:
- reformatted longer parameter lists to have one parameter per-line
(Brendan, patch 1)
- fixed phrasing in various comments to clarify allocation of memory
and added comment to kunit resource tests to clarify why
kunit_put_resource() is used there (Brendan, patch 1)
- changed #define to static inline function (Brendan, patch 2)
- simplified kunit_add_named_resource() to use more of existing
code for non-named resource (Brendan, patch 2)
Alan Maguire (2):
kunit: generalize kunit_resource API beyond allocated resources
kunit: add support for named resources
include/kunit/test.h | 211 +++++++++++++++++++++++++++++++++++++++-------
lib/kunit/kunit-test.c | 111 +++++++++++++++++++-----
lib/kunit/string-stream.c | 14 ++-
lib/kunit/test.c | 172 ++++++++++++++++++++++---------------
4 files changed, 382 insertions(+), 126 deletions(-)
--
1.8.3.1
Make it easier to enable all KUnit fragments. This is useful for kernel
devs or testers, so its easy to get all KUnit tests enabled and if new
gets added they will be enabled as well. Fragments that has to be
builtin will be missed if CONFIG_KUNIT_ALL_TESTS is set as a module.
Signed-off-by: Anders Roxell <anders.roxell(a)linaro.org>
---
lib/kunit/Kconfig | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig
index 95d12e3d6d95..bdeee7639005 100644
--- a/lib/kunit/Kconfig
+++ b/lib/kunit/Kconfig
@@ -41,4 +41,18 @@ config KUNIT_EXAMPLE_TEST
is intended for curious hackers who would like to understand how to
use KUnit for kernel development.
+config KUNIT_ALL_TESTS
+ tristate "All KUnit tests with satisfied dependencies"
+ help
+ Enables all KUnit tests, if they can be enabled.
+ KUnit tests run during boot and output the results to the debug log
+ in TAP format (http://testanything.org/). Only useful for kernel devs
+ running the KUnit test harness, and not intended for inclusion into a
+ production build.
+
+ For more information on KUnit and unit tests in general please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit/.
+
+ If unsure, say N.
+
endif # KUNIT
--
2.20.1
Hi,
Here are some patches to update ftracetest to fix some issues.
- [1/3] Fix coloring of XFAIL
- [2/3] Fix a testcase not to expect just one event entry
- [3/3] Do not use built-in echo because the behavior is different
on dash and bash. (Thanks Liu for reporting!)
Thank you,
---
Masami Hiramatsu (3):
selftests/ftrace: Make XFAIL green color
selftests/ftrace: Pick only the first kprobe event to test
selftests/ftrace: Use /bin/echo instead of built-in echo
tools/testing/selftests/ftrace/ftracetest | 2 +-
tools/testing/selftests/ftrace/test.d/functions | 3 +++
.../ftrace/test.d/kprobe/kprobe_args_type.tc | 2 +-
.../test.d/trigger/trigger-trace-marker-hist.tc | 2 +-
.../trigger-trace-marker-synthetic-kernel.tc | 4 ++++
.../trigger/trigger-trace-marker-synthetic.tc | 4 ++--
6 files changed, 12 insertions(+), 5 deletions(-)
--
Masami Hiramatsu (Linaro) <mhiramat(a)kernel.org>
This series fixes a bug in the map_lookup_and_delete_elem() function which
should check for the FMODE_CAN_READ bit, because it returns data to user space.
The rest of commits fix some typos and comment in selftests and extend the
test_map_wronly test to cover the new check for the BPF_MAP_TYPE_STACK and
BPF_MAP_TYPE_QUEUE map types.
Anton Protopopov (5):
selftests/bpf: fix a typo in test_maps
selftests/bpf: cleanup some file descriptors in test_maps
selftests/bpf: cleanup comments in test_maps
bpf: fix map permissions check
selftests/bpf: add tests for write-only stacks/queues
kernel/bpf/syscall.c | 3 +-
tools/testing/selftests/bpf/test_maps.c | 52 ++++++++++++++++++++++---
2 files changed, 49 insertions(+), 6 deletions(-)
--
2.20.1
Hi!
I'm wondering how out of tree check is supposed to work for make
O=dir run_tests from selftests (or make -C ...) directory?
(both with 051f278e9d81 ("kbuild: replace KBUILD_SRCTREE with
boolean building_out_of_srctree") and without)
make M= ... does not work with run_tests.
--
WBR,
Yauheni Kaliuta