From: John Stultz <john.stultz(a)linaro.org>
[ Upstream commit 4bb9d46d47b105a774f9dca642f5271375bca4b2 ]
When I added the expected error testing, I forgot I need to set
the return to zero when we successfully see an error.
Without this change we only end up testing a single heap
before the test quits.
Cc: Shuah Khan <shuah(a)kernel.org>
Cc: Sumit Semwal <sumit.semwal(a)linaro.org>
Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org>
Cc: Brian Starkey <brian.starkey(a)arm.com>
Cc: Laura Abbott <labbott(a)redhat.com>
Cc: "Andrew F. Davis" <afd(a)ti.com>
Cc: linux-kselftest(a)vger.kernel.org
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
index cd5e1f602ac9..909da9cdda97 100644
--- a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
+++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
@@ -351,6 +351,7 @@ static int test_alloc_errors(char *heap_name)
}
printf("Expected error checking passed\n");
+ ret = 0;
out:
if (dmabuf_fd >= 0)
close(dmabuf_fd);
--
2.25.1
As seccomp_benchmark tries to calibrate how many samples will take more
than 5 seconds to execute, it may end up picking up a number of samples
that take 10 (but up to 12) seconds. As the calibration will take double
that time, it takes around 20 seconds. Then, it executes the whole thing
again, and then once more, with some added overhead. So, the thing might
take more than 40 seconds, which is too close to the 45s timeout.
That is very dependent on the system where it's executed, so may not be
observed always, but it has been observed on x86 VMs. Using a 90s timeout
seems safe enough.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo(a)canonical.com>
---
tools/testing/selftests/seccomp/settings | 1 +
1 file changed, 1 insertion(+)
create mode 100644 tools/testing/selftests/seccomp/settings
diff --git a/tools/testing/selftests/seccomp/settings b/tools/testing/selftests/seccomp/settings
new file mode 100644
index 000000000000..ba4d85f74cd6
--- /dev/null
+++ b/tools/testing/selftests/seccomp/settings
@@ -0,0 +1 @@
+timeout=90
--
2.25.1
hmm_range_fault() returns an array of page frame numbers and flags for
how the pages are mapped in the requested process' page tables. The PFN
can be used to get the struct page with hmm_pfn_to_page() and the page size
order can be determined with compound_order(page) but if the page is larger
than order 0 (PAGE_SIZE), there is no indication that the page is mapped
using a larger page size. To be fully general, hmm_range_fault() would need
to return the mapping size to handle cases like a 1GB compound page being
mapped with 2MB PMD entries. However, the most common case is the mapping
size the same as the underlying compound page size.
This series adds a new output flag to indicate this so that callers know it
is safe to use a large device page table mapping if one is available.
Nouveau and the HMM tests are updated to use the new flag.
Note that this series depends on a patch queued in Ben Skeggs' nouveau
tree ("nouveau/hmm: map pages after migration") and the patches queued
in Jason's HMM tree.
There is also a patch outstanding ("nouveau/hmm: fix nouveau_dmem_chunk
allocations") that is independent of the above and could be applied
before or after.
Ralph Campbell (6):
nouveau/hmm: map pages after migration
nouveau: make nvkm_vmm_ctor() and nvkm_mmu_ptp_get() static
nouveau/hmm: fault one page at a time
mm/hmm: add output flag for compound page mapping
nouveau/hmm: support mapping large sysmem pages
hmm: add tests for HMM_PFN_COMPOUND flag
drivers/gpu/drm/nouveau/nouveau_dmem.c | 46 ++-
drivers/gpu/drm/nouveau/nouveau_dmem.h | 2 +
drivers/gpu/drm/nouveau/nouveau_svm.c | 288 +++++++++---------
drivers/gpu/drm/nouveau/nouveau_svm.h | 5 +
.../gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 6 +-
.../gpu/drm/nouveau/nvkm/subdev/mmu/priv.h | 2 +
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 12 +-
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 3 -
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 29 +-
include/linux/hmm.h | 4 +-
lib/test_hmm.c | 2 +
lib/test_hmm_uapi.h | 2 +
mm/hmm.c | 10 +-
tools/testing/selftests/vm/hmm-tests.c | 76 +++++
14 files changed, 311 insertions(+), 176 deletions(-)
--
2.20.1
To make KUnit easier to use, and to avoid overwriting object and
.config files, the default KUnit build directory is set to .kunit
Fixed up minor merge conflicts - Shuah Khan <skhan(a)linuxfoundation.org>
Fixed this identation error exchanging spaces for tabs between lines
248 and 252:
tools/testing/kunit/kunit.py run --defconfig
File "tools/testing/kunit/kunit.py", line 254
if not linux:
^
TabError: inconsistent use of tabs and spaces in indentation
Signed-off-by: Vitor Massaru Iha <vitor(a)massaru.org>
Reviewed-by: Brendan Higgins <brendanhiggins(a)google.com>
Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=205221
---
version after merge on kunit brach:
v1:
* fix identation (tabs instead of spaces)
v2:
* fix v1 changelog description: fix identation
(spaces instead of tabs, lines 248-252);
* add python error message on commit message;
* fix Link tag on commit message.
---
tools/testing/kunit/kunit.py | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py
index b01838b6f5f9..b3490271a103 100755
--- a/tools/testing/kunit/kunit.py
+++ b/tools/testing/kunit/kunit.py
@@ -169,7 +169,7 @@ def add_common_opts(parser):
parser.add_argument('--build_dir',
help='As in the make command, it specifies the build '
'directory.',
- type=str, default='', metavar='build_dir')
+ type=str, default='.kunit', metavar='build_dir')
parser.add_argument('--make_options',
help='X=Y make option, can be repeated.',
action='append')
@@ -245,12 +245,11 @@ def main(argv, linux=None):
cli_args = parser.parse_args(argv)
if cli_args.subcommand == 'run':
- if cli_args.build_dir:
- if not os.path.exists(cli_args.build_dir):
- os.mkdir(cli_args.build_dir)
- kunit_kernel.kunitconfig_path = os.path.join(
- cli_args.build_dir,
- kunit_kernel.kunitconfig_path)
+ if not os.path.exists(cli_args.build_dir):
+ os.mkdir(cli_args.build_dir)
+ kunit_kernel.kunitconfig_path = os.path.join(
+ cli_args.build_dir,
+ kunit_kernel.kunitconfig_path)
if not linux:
linux = kunit_kernel.LinuxSourceTree()
--
2.26.2
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