- Linux-kselftest-mirror - lists.linaro.org

by Andrea Mayer

This patch set adds the new "strict mode" functionality to the Virtual Routing and Forwarding infrastructure (VRF). Hereafter we discuss the requirements and the main features of the "strict mode" for VRF. On VRF creation, it is necessary to specify the associated routing table used during the lookup operations. Currently, there is no mechanism that avoids creating multiple VRFs sharing the same routing table. In other words, it is not possible to force a one-to-one relationship between a specific VRF and the table associated with it. The "strict mode" imposes that each VRF can be associated to a routing table only if such routing table is not already in use by any other VRF. In particular, the strict mode ensures that: 1) given a specific routing table, the VRF (if exists) is uniquely identified; 2) given a specific VRF, the related table is not shared with any other VRF. Constraints (1) and (2) force a one-to-one relationship between each VRF and the corresponding routing table. The strict mode feature is designed to be network-namespace aware and it can be directly enabled/disabled acting on the "strict_mode" parameter. Read and write operations are carried out through the classic sysctl command on net.vrf.strict_mode path, i.e: sysctl -w net.vrf.strict_mode=1. Only two distinct values {0,1} are accepted by the strict_mode parameter: - with strict_mode=0, multiple VRFs can be associated with the same table. This is the (legacy) default kernel behavior, the same that we experience when the strict mode patch set is not applied; - with strict_mode=1, the one-to-one relationship between the VRFs and the associated tables is guaranteed. In this configuration, the creation of a VRF which refers to a routing table already associated with another VRF fails and the error is returned to the user. The kernel keeps track of the associations between a VRF and the routing table during the VRF setup, in the "management" plane. Therefore, the strict mode does not impact the performance or intrinsic functionality of the data plane in any way. When the strict mode is active it is always possible to disable the strict mode, while the reverse operation is not always allowed. Setting the strict_mode parameter to 0 is equivalent to removing the one-to-one constraint between any single VRF and its associated routing table. Conversely, if the strict mode is disabled and there are multiple VRFs that refer to the same routing table, then it is prohibited to set the strict_mode parameter to 1. In this configuration, any attempt to perform the operation will lead to an error and it will be reported to the user. To enable strict mode once again (by setting the strict_mode parameter to 1), you must first remove all the VRFs that share common tables. There are several use cases which can take advantage from the introduction of the strict mode feature. In particular, the strict mode allows us to: i) guarantee the proper functioning of some applications which deal with routing protocols; ii) perform some tunneling decap operations which require to use specific routing tables for segregating and forwarding the traffic. Considering (i), the creation of different VRFs that point to the same table leads to the situation where two different routing entities believe they have exclusive access to the same table. This leads to the situation where different routing daemons can conflict for gaining routes control due to overlapping tables. By enabling strict mode it is possible to prevent this situation which often occurs due to incorrect configurations done by the users. The ability to enable/disable the strict mode functionality does not depend on the tool used for configuring the networking. In essence, the strict mode patch solves, at the kernel level, what some other patches [1] had tried to solve at the userspace level (using only iproute2) with all the related problems. Considering (ii), the introduction of the strict mode functionality allows us implementing the SRv6 End.DT4 behavior. Such behavior terminates a SR tunnel and it forwards the IPv4 traffic according to the routes present in the routing table supplied during the configuration. The SRv6 End.DT4 can be realized exploiting the routing capabilities made available by the VRF infrastructure. This behavior could leverage a specific VRF for forcing the traffic to be forwarded in accordance with the routes available in the VRF table. Anyway, in order to make the End.DT4 properly work, it must be guaranteed that the table used for the route lookup operations is bound to one and only one VRF. In this way, it is possible to use the table for uniquely retrieving the associated VRF and for routing packets. I would like to thank David Ahern for his constant and valuable support during the design and development phases of this patch set. Comments, suggestions and improvements are very welcome! Thanks, Andrea Mayer [1] https://lore.kernel.org/netdev/20200307205916.15646-1-sharpd@cumulusnetwork… Andrea Mayer (5): l3mdev: add infrastructure for table to VRF mapping vrf: track associations between VRF devices and tables vrf: add sysctl parameter for strict mode vrf: add l3mdev registration for table to VRF device lookup selftests: add selftest for the VRF strict mode drivers/net/vrf.c | 450 +++++++++++++++++- include/net/l3mdev.h | 37 ++ net/l3mdev/l3mdev.c | 95 ++++ .../selftests/net/vrf_strict_mode_test.sh | 390 +++++++++++++++ 4 files changed, 963 insertions(+), 9 deletions(-) create mode 100755 tools/testing/selftests/net/vrf_strict_mode_test.sh -- 2.20.1

5 years, 5 months

5
17
0 0

Re: [RFC,net-next, 0/5] Strict mode for VRF

by David Ahern

On 6/13/20 4:39 PM, Dinesh Dutt wrote: > Understand Andrea. I guess I didn't say it well. What I meant to say was > that the strict mode is the default expected behavior in a classical router. > it has to be off by default for backwards compatibility.

5 years, 5 months

1
0
0 0

[PATCH 0/7] selftests/harness: Switch to TAP output

by Kees Cook

Hi, I finally got around to converting the kselftest_harness.h API to actually use the kselftest.h API so all the tools using it can actually report TAP correctly. As part of this, there are a bunch of related cleanups, API updates, and additions. Thanks! -Kees Kees Cook (7): selftests/clone3: Reorder reporting output selftests: Remove unneeded selftest API headers selftests/binderfs: Fix harness API usage selftests: Add header documentation and helpers selftests/harness: Switch to TAP output selftests/harness: Fully track XFAIL reports selftests/harness: Display signed values correctly tools/testing/selftests/clone3/clone3.c | 2 +- .../selftests/clone3/clone3_clear_sighand.c | 3 +- .../testing/selftests/clone3/clone3_set_tid.c | 2 +- .../filesystems/binderfs/binderfs_test.c | 284 +++++++++--------- tools/testing/selftests/kselftest.h | 78 ++++- tools/testing/selftests/kselftest_harness.h | 142 ++++++--- .../pid_namespace/regression_enomem.c | 1 - .../selftests/pidfd/pidfd_getfd_test.c | 1 - .../selftests/pidfd/pidfd_setns_test.c | 1 - .../selftests/uevent/uevent_filtering.c | 1 - 10 files changed, 330 insertions(+), 185 deletions(-) -- 2.25.1

5 years, 5 months

2
11
0 0

[PATCH] kunit: show error if kunit results are not present

by Uriel Guajardo

From: Uriel Guajardo <urielguajardo(a)google.com> Currently, if the kernel is configured incorrectly or if it crashes before any kunit tests are run, kunit finishes without error, reporting that 0 test cases were run. To fix this, an error is shown when the tap header is not found, which indicates that kunit was not able to run at all. Signed-off-by: Uriel Guajardo <urielguajardo(a)google.com> --- tools/testing/kunit/kunit_parser.py | 8 ++++---- tools/testing/kunit/kunit_tool_test.py | 11 +++++++++++ .../kunit/test_data/test_insufficient_memory.log | Bin 0 -> 856 bytes 3 files changed, 15 insertions(+), 4 deletions(-) create mode 100644 tools/testing/kunit/test_data/test_insufficient_memory.log diff --git a/tools/testing/kunit/kunit_parser.py b/tools/testing/kunit/kunit_parser.py index 64aac9dcd431..f13e0c0d6663 100644 --- a/tools/testing/kunit/kunit_parser.py +++ b/tools/testing/kunit/kunit_parser.py @@ -265,11 +265,9 @@ def bubble_up_suite_errors(test_suite_list: List[TestSuite]) -> TestStatus: return bubble_up_errors(lambda x: x.status, test_suite_list) def parse_test_result(lines: List[str]) -> TestResult: - if not lines: - return TestResult(TestStatus.NO_TESTS, [], lines) consume_non_diagnositic(lines) - if not parse_tap_header(lines): - return None + if not lines or not parse_tap_header(lines): + return TestResult(TestStatus.NO_TESTS, [], lines) test_suites = [] test_suite = parse_test_suite(lines) while test_suite: @@ -282,6 +280,8 @@ def parse_run_tests(kernel_output) -> TestResult: failed_tests = 0 crashed_tests = 0 test_result = parse_test_result(list(isolate_kunit_output(kernel_output))) + if test_result.status == TestStatus.NO_TESTS: + print_with_timestamp(red('[ERROR] ') + 'no kunit output detected') for test_suite in test_result.suites: if test_suite.status == TestStatus.SUCCESS: print_suite_divider(green('[PASSED] ') + test_suite.name) diff --git a/tools/testing/kunit/kunit_tool_test.py b/tools/testing/kunit/kunit_tool_test.py index 984588d6ba95..4a7ef2eef831 100755 --- a/tools/testing/kunit/kunit_tool_test.py +++ b/tools/testing/kunit/kunit_tool_test.py @@ -170,6 +170,17 @@ class KUnitParserTest(unittest.TestCase): result.status) file.close() + def test_no_kunit_output(self): + crash_log = get_absolute_path( + 'test_data/test_insufficient_memory.log') + file = open(crash_log) + print_mock = mock.patch('builtins.print').start() + result = kunit_parser.parse_run_tests( + kunit_parser.isolate_kunit_output(file.readlines())) + print_mock.assert_any_call(StrContains("no kunit output detected")) + print_mock.stop() + file.close() + def test_crashed_test(self): crashed_log = get_absolute_path( 'test_data/test_is_test_passed-crash.log') diff --git a/tools/testing/kunit/test_data/test_insufficient_memory.log b/tools/testing/kunit/test_data/test_insufficient_memory.log new file mode 100644 index 0000000000000000000000000000000000000000..6c9e4da7b6d763a03c0c83302b2faa6dc21a6ea6 GIT binary patch literal 856 zcmbu6Piw<448`yH6xx0L3mw^@hf#VOv}5$J+fZ#KHj8CrJK6H>=Z2=CgO$<hA}n~n z_av{ZCy=#qP-&xMfG4=6vR)i)5n%+={(WUX@f3QQc$@8JeI=@sWh+JEQ*#MXVFVXF z3Ic%)LLrv~p$(Btnp72VZT95Dcs$;|{9!uqlCTqzsVj`yGB}JvL1F#T<`SpJ4?L6& zvLJa#bUk?B5jWafHpCGc^cwdSg)SXJ+Sp0$Q$V&%X;`!D6P@>grwf=!Y9>J$&;ioE z(YWH`vCdK5Yv8@UZFe8*_w@>lK?j;o`2XCkM`zDc9)5TBu*ma#3i~#uEu#ge+Mv@N z!H}`OJ&aI@v}o*ZK;I-rL20Tal*zuYY-cSL^z~bR2OA<uaygqX^7-Rzeh;N?h?hs> F><3Em&*A_8 literal 0 HcmV?d00001 -- 2.27.0.278.ge193c7cf3a9-goog

5 years, 5 months

2
2
0 0

[PATCH v2 0/1] selftests: fpga: dfl: A test for afu interrupt support

by trix＠redhat.com

From: Tom Rix <trix(a)redhat.com> repo: linux-next tag: next-20200611 Start applying selftests to drivers/fpga. While testing out this upcoming change on linux-fpga 'Add interrupt support to FPGA DFL drivers' I did not see any existing fpga tests. So I added one. Change from v1 Use ksft_* functions for reporting Tom Rix (1): selftests: fpga: dfl: A test for afu interrupt support tools/testing/selftests/Makefile | 1 + tools/testing/selftests/drivers/fpga/Makefile | 9 +++++ .../testing/selftests/drivers/fpga/afu_intr.c | 33 +++++++++++++++++++ tools/testing/selftests/drivers/fpga/config | 1 + 4 files changed, 44 insertions(+) create mode 100644 tools/testing/selftests/drivers/fpga/Makefile create mode 100644 tools/testing/selftests/drivers/fpga/afu_intr.c create mode 100644 tools/testing/selftests/drivers/fpga/config -- 2.18.1

5 years, 5 months

1
1
0 0

[PATCH v4 0/4] Fix some issues about kmod

by Tiezhu Yang

v4: - update the commit message with application of patch 3/4 v3: - use the quotes with correct format in the commit message of patch 4/4, sorry for that v2: - update the commit message to explain the detailed reason of patch 3/4 - add this cover letter Tiezhu Yang (4): selftests: kmod: Use variable NAME in kmod_test_0001() kmod: Remove redundant "be an" in the comment kmod: Return directly if module name is empty in request_module() test_kmod: Avoid potential double free in trigger_config_run_type() kernel/kmod.c | 10 +++++++--- lib/test_kmod.c | 2 +- tools/testing/selftests/kmod/kmod.sh | 4 ++-- 3 files changed, 10 insertions(+), 6 deletions(-) -- 2.1.0

5 years, 5 months

2
8
0 0

[PATCH v8 0/8] firmware: add request_partial_firmware_into_buf

by Scott Branden

This patch series adds partial read support via a new call request_partial_firmware_into_buf. Such support is needed when the whole file is not needed and/or only a smaller portion of the file will fit into allocated memory at any one time. In order to accept the enhanced API it has been requested that kernel selftests and upstreamed driver utilize the API enhancement and so are included in this patch series. Also in this patch series is the addition of a new Broadcom VK driver utilizing the new request_firmware_into_buf enhanced API. Further comment followed to add IMA support of the partial reads originating from request_firmware_into_buf calls. Changes from v8: - removed swiss army knife kernel_pread_* style approach and simply add offset parameter in addition to those needed in kernel_read_* functions thus removing need for kernel_pread enum Changes from v6: - update ima_post_read_file check on IMA_FIRMWARE_PARTIAL_READ - adjust new driver i2c-slave-eeprom.c use of request_firmware_into_buf - remove an extern Changes from v5: - add IMA FIRMWARE_PARTIAL_READ support - change kernel pread flags to enum - removed legacy support from driver - driver fixes Changes from v4: - handle reset issues if card crashes - allow driver to have min required msix - add card utilization information Changes from v3: - fix sparse warnings - fix printf format specifiers for size_t - fix 32-bit cross-compiling reports 32-bit shifts - use readl/writel,_relaxed to access pci ioremap memory, removed memory barriers and volatile keyword with such change - driver optimizations for interrupt/poll functionalities Changes from v2: - remove unnecessary code and mutex locks in lib/test_firmware.c - remove VK_IOCTL_ACCESS_BAR support from driver and use pci sysfs instead - remove bitfields - remove Kconfig default m - adjust formatting and some naming based on feedback - fix error handling conditions - use appropriate return codes - use memcpy_toio instead of direct access to PCIE bar Scott Branden (8): fs: introduce kernel_pread_file* support firmware: add offset to request_firmware_into_buf test_firmware: add partial read support for request_firmware_into_buf firmware: test partial file reads of request_firmware_into_buf bcm-vk: add bcm_vk UAPI misc: bcm-vk: add Broadcom VK driver MAINTAINERS: bcm-vk: add maintainer for Broadcom VK Driver ima: add FIRMWARE_PARTIAL_READ support MAINTAINERS | 7 + drivers/base/firmware_loader/firmware.h | 5 + drivers/base/firmware_loader/main.c | 79 +- drivers/misc/Kconfig | 1 + drivers/misc/Makefile | 1 + drivers/misc/bcm-vk/Kconfig | 29 + drivers/misc/bcm-vk/Makefile | 11 + drivers/misc/bcm-vk/bcm_vk.h | 407 +++++ drivers/misc/bcm-vk/bcm_vk_dev.c | 1310 +++++++++++++++ drivers/misc/bcm-vk/bcm_vk_msg.c | 1440 +++++++++++++++++ drivers/misc/bcm-vk/bcm_vk_msg.h | 202 +++ drivers/misc/bcm-vk/bcm_vk_sg.c | 271 ++++ drivers/misc/bcm-vk/bcm_vk_sg.h | 60 + drivers/misc/bcm-vk/bcm_vk_tty.c | 352 ++++ fs/exec.c | 93 +- include/linux/firmware.h | 12 + include/linux/fs.h | 15 + include/uapi/linux/misc/bcm_vk.h | 99 ++ lib/test_firmware.c | 154 +- security/integrity/ima/ima_main.c | 24 +- .../selftests/firmware/fw_filesystem.sh | 80 + 21 files changed, 4599 insertions(+), 53 deletions(-) create mode 100644 drivers/misc/bcm-vk/Kconfig create mode 100644 drivers/misc/bcm-vk/Makefile create mode 100644 drivers/misc/bcm-vk/bcm_vk.h create mode 100644 drivers/misc/bcm-vk/bcm_vk_dev.c create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.c create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.h create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.c create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.h create mode 100644 drivers/misc/bcm-vk/bcm_vk_tty.c create mode 100644 include/uapi/linux/misc/bcm_vk.h -- 2.17.1

5 years, 5 months

1
7
0 0

[PATCH v7 0/8] firmware: add partial read support in request_firmware_into_buf

by Scott Branden

This patch series adds partial read support in request_firmware_into_buf. In order to accept the enhanced API it has been requested that kernel selftests and upstreamed driver utilize the API enhancement and so are included in this patch series. Also in this patch series is the addition of a new Broadcom VK driver utilizing the new request_firmware_into_buf enhanced API. Further comment followed to add IMA support of the partial reads originating from request_firmware_into_buf calls. Changes from v6: - update ima_post_read_file check on IMA_FIRMWARE_PARTIAL_READ - adjust new driver i2c-slave-eeprom.c use of request_firmware_into_buf - remove an extern Changes from v5: - add IMA FIRMWARE_PARTIAL_READ support - change kernel pread flags to enum - removed legacy support from driver - driver fixes Changes from v4: - handle reset issues if card crashes - allow driver to have min required msix - add card utilization information Changes from v3: - fix sparse warnings - fix printf format specifiers for size_t - fix 32-bit cross-compiling reports 32-bit shifts - use readl/writel,_relaxed to access pci ioremap memory, removed memory barriers and volatile keyword with such change - driver optimizations for interrupt/poll functionalities Changes from v2: - remove unnecessary code and mutex locks in lib/test_firmware.c - remove VK_IOCTL_ACCESS_BAR support from driver and use pci sysfs instead - remove bitfields - remove Kconfig default m - adjust formatting and some naming based on feedback - fix error handling conditions - use appropriate return codes - use memcpy_toio instead of direct access to PCIE bar Scott Branden (8): fs: introduce kernel_pread_file* support firmware: add offset to request_firmware_into_buf test_firmware: add partial read support for request_firmware_into_buf firmware: test partial file reads of request_firmware_into_buf bcm-vk: add bcm_vk UAPI misc: bcm-vk: add Broadcom VK driver MAINTAINERS: bcm-vk: add maintainer for Broadcom VK Driver ima: add FIRMWARE_PARTIAL_READ support MAINTAINERS | 7 + drivers/base/firmware_loader/firmware.h | 5 + drivers/base/firmware_loader/main.c | 59 +- drivers/i2c/i2c-slave-eeprom.c | 4 +- drivers/misc/Kconfig | 1 + drivers/misc/Makefile | 1 + drivers/misc/bcm-vk/Kconfig | 29 + drivers/misc/bcm-vk/Makefile | 11 + drivers/misc/bcm-vk/bcm_vk.h | 408 +++++ drivers/misc/bcm-vk/bcm_vk_dev.c | 1312 +++++++++++++++ drivers/misc/bcm-vk/bcm_vk_msg.c | 1438 +++++++++++++++++ drivers/misc/bcm-vk/bcm_vk_msg.h | 201 +++ drivers/misc/bcm-vk/bcm_vk_sg.c | 271 ++++ drivers/misc/bcm-vk/bcm_vk_sg.h | 60 + drivers/misc/bcm-vk/bcm_vk_tty.c | 352 ++++ drivers/soc/qcom/mdt_loader.c | 7 +- fs/exec.c | 101 +- include/linux/firmware.h | 8 +- include/linux/fs.h | 30 + include/uapi/linux/misc/bcm_vk.h | 99 ++ lib/test_firmware.c | 144 +- security/integrity/ima/ima_main.c | 24 +- .../selftests/firmware/fw_filesystem.sh | 80 + 23 files changed, 4598 insertions(+), 54 deletions(-) create mode 100644 drivers/misc/bcm-vk/Kconfig create mode 100644 drivers/misc/bcm-vk/Makefile create mode 100644 drivers/misc/bcm-vk/bcm_vk.h create mode 100644 drivers/misc/bcm-vk/bcm_vk_dev.c create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.c create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.h create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.c create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.h create mode 100644 drivers/misc/bcm-vk/bcm_vk_tty.c create mode 100644 include/uapi/linux/misc/bcm_vk.h -- 2.17.1

5 years, 5 months

3
17
0 0

[PATCH v4 kunit-next 0/2] kunit: extend kunit resources API

by Alan Maguire

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 v3: - removed unused "init" field from "struct kunit_resources" (Brendan) 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 Alan Maguire (2): kunit: generalize kunit_resource API beyond allocated resources kunit: add support for named resources include/kunit/test.h | 210 +++++++++++++++++++++++++++++++++++++++------- lib/kunit/kunit-test.c | 111 +++++++++++++++++++----- lib/kunit/string-stream.c | 14 ++-- lib/kunit/test.c | 171 ++++++++++++++++++++++--------------- 4 files changed, 380 insertions(+), 126 deletions(-) -- 1.8.3.1

5 years, 5 months

3
4
0 0

[PATCH v8 0/5] KUnit-KASAN Integration

by David Gow

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: - "kunit: extend kunit resources API" [1] - "Fix some incompatibilites between KASAN and FORTIFY_SOURCE" [2] - This is already upstream for 5.8[3,4] Changes from v7: - Rebased on top of kselftest/kunit - Rebased on top of v4 of the kunit resources API[1] - Rebased on top of v4 of the FORTIFY_SOURCE fix[2,3,4] - Updated the Kconfig entry to support KUNIT_ALL_TESTS 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 [4] 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/CAFd5g46Uu_5TG89uOm0Dj5CMq+11cwjBns… [2] https://lore.kernel.org/linux-mm/20200424145521.8203-1-dja@axtens.net/ [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [5] 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 | 19 +- 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, 515 insertions(+), 403 deletions(-) create mode 100644 lib/test_kasan_module.c -- 2.27.0.278.ge193c7cf3a9-goog

5 years, 5 months

3
9
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror