usage.rst goes into a detailed about faking out classes, but currently
lacks wording about how one might idiomatically test a range of inputs.
Give an example of how one might test a hash function via macros/helper
funcs and a table-driven test and very briefly discuss pros and cons.
Also highlight the KUNIT_EXPECT_*_MSG() variants (that aren't mentioned
elsewhere [1]) which are particularly useful in these situations.
It is also criminally underused at the moment, only appearing in 2
tests (both written by people involved in KUnit).
[1] not even on
https://www.kernel.org/doc/html/latest/dev-tools/kunit/api/test.html
Signed-off-by: Daniel Latypov <dlatypov(a)google.com>
---
Documentation/dev-tools/kunit/usage.rst | 66 +++++++++++++++++++++++++
1 file changed, 66 insertions(+)
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
index 62142a47488c..317390df2b96 100644
--- a/Documentation/dev-tools/kunit/usage.rst
+++ b/Documentation/dev-tools/kunit/usage.rst
@@ -451,6 +451,72 @@ We can now use it to test ``struct eeprom_buffer``:
destroy_eeprom_buffer(ctx->eeprom_buffer);
}
+Testing various inputs
+----------------------
+
+Testing just a few inputs might not be enough to have confidence that the code
+works correctly, e.g. for a hash function.
+
+In such cases, it can be helpful to have a helper macro or function, e.g. this
+fictitious example for ``md5sum(1)``
+
+.. code-block:: c
+
+ /* Note: the cast is to satisfy overly strict type-checking. */
+ #define TEST_MD5(in, want) \
+ md5sum(in, out); \
+ KUNIT_EXPECT_STREQ_MSG(test, (char *)out, want, "md5sum(%s)", in);
+
+ char out[16];
+ TEST_MD5("hello world", "5eb63bbbe01eeed093cb22bb8f5acdc3");
+ TEST_MD5("hello world!", "fc3ff98e8c6a0d3087d515c0473f8677");
+
+Note the use of ``KUNIT_EXPECT_STREQ_MSG`` to give more context when it fails
+and make it easier to track down. (Yes, in this example, ``want`` is likely
+going to be unique enough on its own).
+
+The ``_MSG`` variants are even more useful when the same expectation is called
+multiple times (in a loop or helper function) and thus the line number isn't
+enough to identify what failed, like below.
+
+In some cases, it can be helpful to write a *table-driven test* instead, e.g.
+
+.. code-block:: c
+
+ int i;
+ char out[16];
+
+ struct md5_test_case {
+ const char *str;
+ const char *md5;
+ };
+
+ struct md5_test_case cases[] = {
+ {
+ .str = "hello world",
+ .md5 = "5eb63bbbe01eeed093cb22bb8f5acdc3",
+ },
+ {
+ .str = "hello world!",
+ .md5 = "fc3ff98e8c6a0d3087d515c0473f8677",
+ },
+ };
+ for (i = 0; i < ARRAY_SIZE(cases); ++i) {
+ md5sum(cases[i].str, out);
+ KUNIT_EXPECT_STREQ_MSG(test, (char *)out, cases[i].md5,
+ "md5sum(%s)", cases[i].str);
+ }
+
+
+There's more boilerplate involved, but it can:
+
+* be more readable when there are multiple inputs/outputs thanks to field names,
+
+ * E.g. see ``fs/ext4/inode-test.c`` for an example of both.
+* reduce duplication if test cases can be shared across multiple tests.
+
+ * E.g. if we had a magical ``undo_md5sum`` function, we could reuse ``cases``.
+
.. _kunit-on-non-uml:
KUnit on non-UML architectures
base-commit: 77c8473edf7f7664137f555cfcdc8c460bbd947d
--
2.29.1.341.ge80a0c044ae-goog
Hi,
This is the v7 of syscall user dispatch. This version is a bit
different from v6 on the following points, after the modifications
requested on that submission.
* The interface no longer receives <start>,<end> end parameters, but
<start>,<length> as suggested by PeterZ.
* Syscall User Dispatch is now done before ptrace, and this means there
is some SYSCALL_WORK_EXIT work that needs to be done. No challenges
there, but I'd like to draw attention to that region of the code that
is new in this submission.
* The previous TIF_SYSCALL_USER_DISPATCH is now handled through
SYSCALL_WORK flags.
* Introduced a new test as patch 6, which benchmarks the fast submission
path and test the return in blocked selector state.
* Nothing is architecture dependent anymore. No config switches. It
only depends on CONFIG_GENERIC_ENTRY.
Other smaller changes are documented one each commit.
This was tested using the kselftests tests in patch 5 and 6 and compiled
tested with !CONFIG_GENERIC_ENTRY.
This patchset is based on the core/entry branch of the TIP tree.
A working tree with this patchset is available at:
https://gitlab.collabora.com/krisman/linux -b syscall-user-dispatch-v7
Previous submissions are archived at:
RFC/v1: https://lkml.org/lkml/2020/7/8/96
v2: https://lkml.org/lkml/2020/7/9/17
v3: https://lkml.org/lkml/2020/7/12/4
v4: https://www.spinics.net/lists/linux-kselftest/msg16377.html
v5: https://lkml.org/lkml/2020/8/10/1320
v6: https://lkml.org/lkml/2020/9/4/1122
Gabriel Krisman Bertazi (7):
x86: vdso: Expose sigreturn address on vdso to the kernel
signal: Expose SYS_USER_DISPATCH si_code type
kernel: Implement selective syscall userspace redirection
entry: Support Syscall User Dispatch on common syscall entry
selftests: Add kselftest for syscall user dispatch
selftests: Add benchmark for syscall user dispatch
docs: Document Syscall User Dispatch
.../admin-guide/syscall-user-dispatch.rst | 87 +++++
arch/x86/entry/vdso/vdso2c.c | 2 +
arch/x86/entry/vdso/vdso32/sigreturn.S | 2 +
arch/x86/entry/vdso/vma.c | 15 +
arch/x86/include/asm/elf.h | 2 +
arch/x86/include/asm/vdso.h | 2 +
arch/x86/kernel/signal_compat.c | 2 +-
fs/exec.c | 3 +
include/linux/entry-common.h | 2 +
include/linux/sched.h | 2 +
include/linux/syscall_user_dispatch.h | 40 +++
include/linux/thread_info.h | 2 +
include/uapi/asm-generic/siginfo.h | 3 +-
include/uapi/linux/prctl.h | 5 +
kernel/entry/Makefile | 2 +-
kernel/entry/common.c | 17 +
kernel/entry/common.h | 16 +
kernel/entry/syscall_user_dispatch.c | 102 ++++++
kernel/fork.c | 1 +
kernel/sys.c | 5 +
tools/testing/selftests/Makefile | 1 +
.../syscall_user_dispatch/.gitignore | 3 +
.../selftests/syscall_user_dispatch/Makefile | 9 +
.../selftests/syscall_user_dispatch/config | 1 +
.../syscall_user_dispatch/sud_benchmark.c | 200 +++++++++++
.../syscall_user_dispatch/sud_test.c | 310 ++++++++++++++++++
26 files changed, 833 insertions(+), 3 deletions(-)
create mode 100644 Documentation/admin-guide/syscall-user-dispatch.rst
create mode 100644 include/linux/syscall_user_dispatch.h
create mode 100644 kernel/entry/common.h
create mode 100644 kernel/entry/syscall_user_dispatch.c
create mode 100644 tools/testing/selftests/syscall_user_dispatch/.gitignore
create mode 100644 tools/testing/selftests/syscall_user_dispatch/Makefile
create mode 100644 tools/testing/selftests/syscall_user_dispatch/config
create mode 100644 tools/testing/selftests/syscall_user_dispatch/sud_benchmark.c
create mode 100644 tools/testing/selftests/syscall_user_dispatch/sud_test.c
--
2.29.2
It looks like the seccomp selftests were never actually built for sh.
This fixes it, though I don't have an environment to do a runtime test
of it yet.
Fixes: 0bb605c2c7f2b4b3 ("sh: Add SECCOMP_FILTER")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c b/tools/testing/selftests/seccomp/seccomp_bpf.c
index 7f7ecfcd66db..26c72f2b61b1 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -1804,8 +1804,8 @@ TEST_F(TRACE_poke, getpid_runs_normally)
#define SYSCALL_RET(_regs) (_regs).a[(_regs).windowbase * 4 + 2]
#elif defined(__sh__)
# define ARCH_REGS struct pt_regs
-# define SYSCALL_NUM(_regs) (_regs).gpr[3]
-# define SYSCALL_RET(_regs) (_regs).gpr[0]
+# define SYSCALL_NUM(_regs) (_regs).regs[3]
+# define SYSCALL_RET(_regs) (_regs).regs[0]
#else
# error "Do not know how to find your architecture's registers and syscalls"
#endif
--
2.25.1
Hi,
This patch series fixes some issues and makes the Landlock filesystem
access-control more consistent and deterministic when stacking multiple
rulesets. This is checked by current and new tests. I also extended
documentation and example to help users.
This series can be applied on top of
https://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git/…
Regards,
Mickaël Salaün (9):
landlock: Fix memory allocation error handling
landlock: Cosmetic fixes for filesystem management
landlock: Enforce deterministic interleaved path rules
landlock: Always intersect access rights
landlock: Add extra checks when inserting a rule
selftests/landlock: Extend layout1.inherit_superset
landlock: Clean up get_ruleset_from_fd()
landlock: Add help to enable Landlock as a stacked LSM
landlock: Extend documentation about limitations
Documentation/userspace-api/landlock.rst | 17 +++
samples/landlock/sandboxer.c | 21 +++-
security/landlock/Kconfig | 4 +-
security/landlock/fs.c | 67 +++++-----
security/landlock/object.c | 5 +-
security/landlock/ruleset.c | 34 ++---
security/landlock/syscall.c | 24 ++--
tools/testing/selftests/landlock/fs_test.c | 140 +++++++++++++++++++--
8 files changed, 239 insertions(+), 73 deletions(-)
base-commit: 96b3198c4025c11347651700b77e45a686d78553
--
2.29.2
From: Zi Yan <ziy(a)nvidia.com>
Hi all,
With Matthew's THP in pagecache patches[1], we will be able to handle any size
pagecache THPs, but currently split_huge_page can only split a THP to order-0
pages. This can easily erase the benefit of having pagecache THPs, when
operations like truncate might want to keep pages larger than order-0. In
response, here is the patches to add support for splitting a THP to any lower
order pages. In addition, this patchset prepares for my PUD THP patchset[2],
since splitting a PUD THP to multiple PMD THPs can be handled by
split_huge_page_to_list_to_order function added by this patchset, which reduces
a lot of redundant code without just replicating split_huge_page for PUD THP.
To help the tests of splitting huge pages, I added a new debugfs interface
at <debugfs>/split_huge_pages_in_range_pid, so developers can split THPs in a
given range from a process with the given pid by writing
"<pid>,<vaddr_start>,<vaddr_end>,<to_order>" to the interface. I also added a
new test program to test 1) splitting PMD THPs, 2) splitting PTE-mapped THPs,
3) splitting pagecache THPs to any lower order, 4) truncating a pagecache
THP to a page with a lower order, and 5) punching holes in a pagecache THP to
cause splitting THPs to lower order THPs.
The patchset is on top of Matthew's pagecache/next tree[3].
* Patch 1 is cherry-picked from Matthew's recent xarray fix [4] just to make sure
Patch 3 to 7 can run without problem. I let Matthew decide how it should get
picked up.
* Patch 2 is self-contained and can be merged if it looks OK.
Comments and/or suggestions are welcome.
ChangeLog
===
>From RFC:
1. Fixed debugfs to handle splitting PTE-mapped THPs properly and added stats
for split THPs.
2. Added a new test case for splitting PTE-mapped THPs. Each of the four PTEs
points to a different subpage from four THPs and used kpageflags to check
whether a PTE points to a THP or not (AnonHugePages from smap does not show
PTE-mapped THPs).
3. mem_cgroup_split_huge_fixup() takes order instead of nr.
4. split_page_owner takes old_order and new_order instead of nr and new_order.
5. Corrected __split_page_owner declaration and fixed its implementation when
splitting a THP to a new order.
6. Renamed left to remaining in truncate_inode_partial_page().
7. Use VM_BUG_ON instead of WARN_ONCE when splitting a THP to the unsupported
order-0 and splitting anonymous THPs to non-zero orders.
8. Added punching holes in a file as a new pagecache THP split test case, which
uncovered an xarray bug.
[1] https://lore.kernel.org/linux-mm/20201029193405.29125-1-willy@infradead.org/
[2] https://lore.kernel.org/linux-mm/20200928175428.4110504-1-zi.yan@sent.com/
[3] https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/next
[4] https://git.infradead.org/users/willy/xarray.git
Matthew Wilcox (Oracle) (1):
XArray: Fix splitting to non-zero orders
Zi Yan (6):
mm: huge_memory: add new debugfs interface to trigger split huge page
on any page range.
mm: memcg: make memcg huge page split support any order split.
mm: page_owner: add support for splitting to any order in split
page_owner.
mm: thp: split huge page to any lower order pages.
mm: truncate: split thp to a non-zero order if possible.
mm: huge_memory: enable debugfs to split huge pages to any order.
include/linux/huge_mm.h | 8 +
include/linux/memcontrol.h | 5 +-
include/linux/page_owner.h | 10 +-
lib/test_xarray.c | 26 +-
lib/xarray.c | 4 +-
mm/huge_memory.c | 219 ++++++--
mm/internal.h | 1 +
mm/memcontrol.c | 6 +-
mm/migrate.c | 2 +-
mm/page_alloc.c | 2 +-
mm/page_owner.c | 13 +-
mm/swap.c | 1 -
mm/truncate.c | 29 +-
tools/testing/selftests/vm/.gitignore | 1 +
tools/testing/selftests/vm/Makefile | 1 +
.../selftests/vm/split_huge_page_test.c | 479 ++++++++++++++++++
16 files changed, 742 insertions(+), 65 deletions(-)
create mode 100644 tools/testing/selftests/vm/split_huge_page_test.c
--
2.28.0
On Tue, 17 Nov 2020 at 19:02, Greg Kroah-Hartman
<gregkh(a)linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.9.9 release.
> There are 255 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 19 Nov 2020 12:20:51 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.9-rc1.…
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <lkft(a)linaro.org>
NOTE:
1)
BUG: Invalid wait context on arm64 db410c device while booting.
This issue has not reproduced after several testing loops.
https://lore.kernel.org/stable/CA+G9fYsk54r9Re4E9BWpqsoxLjpCvxRKFWRgdiKVcPo…
2)
kselftest test suite version upgrade to v5.9
3)
While running kselftest netfilter on x86, i386, arm64 and arm devices
the following kernel warning was noticed.
WARNING: at net/netfilter/nf_tables_api.c:622
lockdep_nfnl_nft_mutex_not_held+0x19/0x20 [nf_tables]
https://lore.kernel.org/linux-kselftest/CA+G9fYvFUpODs+NkSYcnwKnXm62tmP=ksL…
4)
>From this release we have started building kernels with clang-10 toolchain
and testing LTP testsuite on qemu_arm64, qemu_arm, qemu_x86_64 and qemu_i386.
Summary
------------------------------------------------------------------------
kernel: 5.9.9-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.9.y
git commit: fb1622495321923cbb1ae2c6cf2da1e9ca286800
git describe: v5.9.8-256-gfb1622495321
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.9.y/build/v5.9.8…
No regressions (compared to build v5.9.8)
No fixes (compared to build v5.9.8)
Ran 52946 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-i386-clang
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- x15
- x86
- x86-kasan
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* perf
* v4l2-compliance
* ltp-controllers-tests
* ltp-cve-tests
* network-basic-tests
* kselftest
* ltp-open-posix-tests
* kvm-unit-tests
* kunit
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
--
Linaro LKFT
https://lkft.linaro.org