BusyBox diff doesn't support the GNU diff '--LTYPE-line-format' options
that were used in the selftests to filter older kernel log messages from
dmesg output.
Use "comm" which is more available in smaller boot environments.
Reported-by: Naresh Kamboju <naresh.kamboju(a)linaro.org>
Signed-off-by: Joe Lawrence <joe.lawrence(a)redhat.com>
---
based-on: livepatching.git/for-5.9/selftests-cleanup
merge-thru: livepatching.git
tools/testing/selftests/livepatch/functions.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/livepatch/functions.sh b/tools/testing/selftests/livepatch/functions.sh
index 36648ca367c2..408529d94ddb 100644
--- a/tools/testing/selftests/livepatch/functions.sh
+++ b/tools/testing/selftests/livepatch/functions.sh
@@ -277,7 +277,7 @@ function check_result {
# help differentiate repeated testing runs. Remove them with a
# post-comparison sed filter.
- result=$(dmesg | diff --changed-group-format='%>' --unchanged-group-format='' "$SAVED_DMESG" - | \
+ result=$(dmesg | comm -13 "$SAVED_DMESG" - | \
grep -e 'livepatch:' -e 'test_klp' | \
grep -v '\(tainting\|taints\) kernel' | \
sed 's/^\[[ 0-9.]*\] //')
--
2.21.3
On Thu, Jul 09, 2020 at 09:27:43AM -0700, Andy Lutomirski wrote:
> On Thu, Jul 9, 2020 at 9:22 AM Dave Hansen <dave.hansen(a)intel.com> wrote:
> >
> > On 7/9/20 9:07 AM, Andy Lutomirski wrote:
> > > On Thu, Jul 9, 2020 at 8:56 AM Dave Hansen <dave.hansen(a)intel.com> wrote:
> > >> On 7/9/20 8:44 AM, Andersen, John wrote:
> > >>> Bits which are allowed to be pinned default to WP for CR0 and SMEP,
> > >>> SMAP, and UMIP for CR4.
> > >> I think it also makes sense to have FSGSBASE in this set.
> > >>
> > >> I know it hasn't been tested, but I think we should do the legwork to
> > >> test it. If not in this set, can we agree that it's a logical next step?
> > > I have no objection to pinning FSGSBASE, but is there a clear
> > > description of the threat model that this whole series is meant to
> > > address? The idea is to provide a degree of protection against an
> > > attacker who is able to convince a guest kernel to write something
> > > inappropriate to CR4, right? How realistic is this?
> >
> > If a quick search can find this:
> >
> > > https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-…
> >
> > I'd pretty confident that the guys doing actual bad things have it in
> > their toolbox too.
> >
>
> True, but we have the existing software CR4 pinning. I suppose the
> virtualization version is stronger.
>
Yes, as Kees said this will be stronger because it stops ROP and other gadget
based techniques which avoid the use of native_write_cr0/4().
With regards to what should be done in this patchset and what in other
patchsets. I have a fix for kexec thanks to Arvind's note about
TRAMPOLINE_32BIT_CODE_SIZE. The physical host boots fine now and the virtual
one can kexec fine.
What remains to be done on that front is to add some identifying information to
the kernel image to declare that it supports paravirtualized control register
pinning or not.
Liran suggested adding a section to the built image acting as a flag to signify
support for being kexec'd by a kernel with pinning enabled. If anyone has any
opinions on how they'd like to see this implemented please let me know.
Otherwise I'll just take a stab at it and you'll all see it hopefully in the
next version.
With regards to FSGSBASE, are we open to validating and adding that to the
DEFAULT set as a part of a separate patchset? This patchset is focused on
replicating the functionality we already have natively.
Hi,
v2:
- switch harness from XFAIL to SKIP
- pass skip reason from test into TAP output
- add acks/reviews
v1: https://lore.kernel.org/lkml/20200611224028.3275174-1-keescook@chromium.org/
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 (8):
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: Refactor XFAIL into SKIP
selftests/harness: Display signed values correctly
selftests/harness: Report skip reason
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 | 169 ++++++++---
.../pid_namespace/regression_enomem.c | 1 -
.../selftests/pidfd/pidfd_getfd_test.c | 1 -
.../selftests/pidfd/pidfd_setns_test.c | 1 -
tools/testing/selftests/seccomp/seccomp_bpf.c | 8 +-
.../selftests/uevent/uevent_filtering.c | 1 -
11 files changed, 356 insertions(+), 194 deletions(-)
--
2.25.1
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster(a)al2klimov.de>
---
Continuing my work started at 93431e0607e5.
See also: git log --oneline '--author=Alexander A. Klimov <grandmaster(a)al2klimov.de>' v5.7..master
(Actually letting a shell for loop submit all this stuff for me.)
If there are any URLs to be removed completely or at least not just HTTPSified:
Just clearly say so and I'll *undo my change*.
See also: https://lkml.org/lkml/2020/6/27/64
If there are any valid, but yet not changed URLs:
See: https://lkml.org/lkml/2020/6/26/837
If you apply the patch, please let me know.
Sorry again to all maintainers who complained about subject lines.
Now I realized that you want an actually perfect prefixes,
not just subsystem ones.
I tried my best...
And yes, *I could* (at least half-)automate it.
Impossible is nothing! :)
tools/testing/selftests/futex/include/atomic.h | 2 +-
tools/testing/selftests/futex/include/futextest.h | 2 +-
tools/testing/selftests/powerpc/ptrace/perf-hwbreak.c | 2 +-
tools/testing/selftests/vDSO/parse_vdso.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/futex/include/atomic.h b/tools/testing/selftests/futex/include/atomic.h
index 428bcd921bb5..23703ecfcd68 100644
--- a/tools/testing/selftests/futex/include/atomic.h
+++ b/tools/testing/selftests/futex/include/atomic.h
@@ -5,7 +5,7 @@
*
* DESCRIPTION
* GCC atomic builtin wrappers
- * http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html
+ * https://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html
*
* AUTHOR
* Darren Hart <dvhart(a)linux.intel.com>
diff --git a/tools/testing/selftests/futex/include/futextest.h b/tools/testing/selftests/futex/include/futextest.h
index ddbcfc9b7bac..2a210c482f7b 100644
--- a/tools/testing/selftests/futex/include/futextest.h
+++ b/tools/testing/selftests/futex/include/futextest.h
@@ -211,7 +211,7 @@ futex_cmp_requeue_pi(futex_t *uaddr, futex_t val, futex_t *uaddr2, int nr_wake,
* @newval: The new value to try and assign the futex
*
* Implement cmpxchg using gcc atomic builtins.
- * http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html
+ * https://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html
*
* Return the old futex value.
*/
diff --git a/tools/testing/selftests/powerpc/ptrace/perf-hwbreak.c b/tools/testing/selftests/powerpc/ptrace/perf-hwbreak.c
index c1f324afdbf3..946c52e1f327 100644
--- a/tools/testing/selftests/powerpc/ptrace/perf-hwbreak.c
+++ b/tools/testing/selftests/powerpc/ptrace/perf-hwbreak.c
@@ -12,7 +12,7 @@
* times. Then check the output count from perf is as expected.
*
* Based on:
- * http://ozlabs.org/~anton/junkcode/perf_events_example1.c
+ * https://ozlabs.org/~anton/junkcode/perf_events_example1.c
*
* Copyright (C) 2018 Michael Neuling, IBM Corporation.
*/
diff --git a/tools/testing/selftests/vDSO/parse_vdso.c b/tools/testing/selftests/vDSO/parse_vdso.c
index 413f75620a35..3413fc00c835 100644
--- a/tools/testing/selftests/vDSO/parse_vdso.c
+++ b/tools/testing/selftests/vDSO/parse_vdso.c
@@ -5,7 +5,7 @@
* This code is meant to be linked in to various programs that run on Linux.
* As such, it is available with as few restrictions as possible. This file
* is licensed under the Creative Commons Zero License, version 1.0,
- * available at http://creativecommons.org/publicdomain/zero/1.0/legalcode
+ * available at https://creativecommons.org/publicdomain/zero/1.0/legalcode
*
* The vDSO is a regular ELF DSO that the kernel maps into user space when
* it starts a program. It works equally well in statically and dynamically
--
2.27.0
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster(a)al2klimov.de>
---
Continuing my work started at 93431e0607e5.
See also: git log --oneline '--author=Alexander A. Klimov <grandmaster(a)al2klimov.de>' v5.7..master
(Actually letting a shell for loop submit all this stuff for me.)
If there are any URLs to be removed completely or at least not just HTTPSified:
Just clearly say so and I'll *undo my change*.
See also: https://lkml.org/lkml/2020/6/27/64
If there are any valid, but yet not changed URLs:
See: https://lkml.org/lkml/2020/6/26/837
If you apply the patch, please let me know.
Sorry again to all maintainers who complained about subject lines.
Now I realized that you want an actually perfect prefixes,
not just subsystem ones.
I tried my best...
And yes, *I could* (at least half-)automate it.
Impossible is nothing! :)
tools/testing/selftests/rcutorture/doc/rcu-test-image.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/rcutorture/doc/rcu-test-image.txt b/tools/testing/selftests/rcutorture/doc/rcu-test-image.txt
index 449cf579d6f9..cc280ba157a3 100644
--- a/tools/testing/selftests/rcutorture/doc/rcu-test-image.txt
+++ b/tools/testing/selftests/rcutorture/doc/rcu-test-image.txt
@@ -36,7 +36,7 @@ References:
https://help.ubuntu.com/community/JeOSVMBuilderhttp://wiki.libvirt.org/page/UbuntuKVMWalkthroughhttp://www.moe.co.uk/2011/01/07/pci_add_option_rom-failed-to-find-romfile-p… -- "apt-get install kvm-pxe"
- http://www.landley.net/writing/rootfs-howto.html
- http://en.wikipedia.org/wiki/Initrd
- http://en.wikipedia.org/wiki/Cpio
+ https://www.landley.net/writing/rootfs-howto.html
+ https://en.wikipedia.org/wiki/Initrd
+ https://en.wikipedia.org/wiki/Cpiohttp://wiki.libvirt.org/page/UbuntuKVMWalkthrough
--
2.27.0
v2:
- check for CONFIG_USER_NS
- add review
- fix Cc list
v1: https://lore.kernel.org/lkml/20200710185156.2437687-1-keescook@chromium.org
Hi,
This fixes the seccomp selftests to pass (with SKIPs) for regular users.
I intend to put this in my for-next/seccomp tree (to avoid further conflicts
with the kselftest tree).
(and for those following along, this is effectively based on the -next tree)
-Kees
Kees Cook (2):
selftests/seccomp: Add SKIPs for failed unshare()
selftests/seccomp: Set NNP for TSYNC ESRCH flag test
tools/testing/selftests/seccomp/config | 1 +
tools/testing/selftests/seccomp/seccomp_bpf.c | 15 +++++++++++++--
2 files changed, 14 insertions(+), 2 deletions(-)
--
2.25.1
Since the BPF_PROG_TYPE_CGROUP_SOCKOPT verifier test does not set an
attach type, bpf_prog_load_check_attach() disallows loading the program
and the test is always skipped:
#434/p perfevent for cgroup sockopt SKIP (unsupported program type 25)
Fix the issue by setting a valid attach type.
Fixes: 0456ea170cd6 ("bpf: Enable more helpers for BPF_PROG_TYPE_CGROUP_{DEVICE,SYSCTL,SOCKOPT}")
Signed-off-by: Jean-Philippe Brucker <jean-philippe(a)linaro.org>
---
tools/testing/selftests/bpf/verifier/event_output.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/bpf/verifier/event_output.c b/tools/testing/selftests/bpf/verifier/event_output.c
index 99f8f582c02b..c5e805980409 100644
--- a/tools/testing/selftests/bpf/verifier/event_output.c
+++ b/tools/testing/selftests/bpf/verifier/event_output.c
@@ -112,6 +112,7 @@
"perfevent for cgroup sockopt",
.insns = { __PERF_EVENT_INSNS__ },
.prog_type = BPF_PROG_TYPE_CGROUP_SOCKOPT,
+ .expected_attach_type = BPF_CGROUP_SETSOCKOPT,
.fixup_map_event_output = { 4 },
.result = ACCEPT,
.retval = 1,
--
2.27.0
Hi Linus,
Please pull the following Kselftest fixes update for Linux 5.8-rc5.
This Kselftest fixes update for Linux 5.8-rc5 consists of tmp2 test
changes to run on python3 and kselftest framework fix to incorrect
return type.
diff is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit 377ff83083c953dd58c5a030b3c9b5b85d8cc727:
selftests: tpm: Use /bin/sh instead of /bin/bash (2020-06-29 14:19:38
-0600)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-fixes-5.8-rc5
for you to fetch changes up to 3c01655ac82eb6d1cc2cfe9507031f1b5e0a6df1:
kselftest: ksft_test_num return type should be unsigned (2020-07-06
15:07:47 -0600)
----------------------------------------------------------------
linux-kselftest-fixes-5.8-rc5
This Kselftest fixes update for Linux 5.8-rc5 consists of tmp2 test
changes to run on python3 and kselftest framework fix to incorrect
return type.
----------------------------------------------------------------
Paolo Bonzini (1):
kselftest: ksft_test_num return type should be unsigned
Pengfei Xu (1):
selftests: tpm: upgrade TPM2 tests from Python 2 to Python 3
tools/testing/selftests/kselftest.h | 2 +-
tools/testing/selftests/tpm2/test_smoke.sh | 4 +--
tools/testing/selftests/tpm2/test_space.sh | 2 +-
tools/testing/selftests/tpm2/tpm2.py | 56
++++++++++++++++--------------
tools/testing/selftests/tpm2/tpm2_tests.py | 39 +++++++++++----------
5 files changed, 53 insertions(+), 50 deletions(-)
----------------------------------------------------------------
The goal for this series is to avoid device private memory TLB
invalidations when migrating a range of addresses from system
memory to device private memory and some of those pages have already
been migrated. The approach taken is to introduce a new mmu notifier
invalidation event type and use that in the device driver to skip
invalidation callbacks from migrate_vma_setup(). The device driver is
also then expected to handle device MMU invalidations as part of the
migrate_vma_setup(), migrate_vma_pages(), migrate_vma_finalize() process.
Note that this is opt-in. A device driver can simply invalidate its MMU
in the mmu notifier callback and not handle MMU invalidations in the
migration sequence.
This series is based on linux-5.8.0-rc4 and the patches I sent for
("mm/hmm/nouveau: add PMD system memory mapping")
https://lore.kernel.org/linux-mm/20200701225352.9649-1-rcampbell@nvidia.com
There are no logical dependencies, but there would be merge conflicts
which could be resolved if this were to be applied before the other
series.
Also, this replaces the need for the following two patches I sent:
("mm: fix migrate_vma_setup() src_owner and normal pages")
https://lore.kernel.org/linux-mm/20200622222008.9971-1-rcampbell@nvidia.com
("nouveau: fix mixed normal and device private page migration")
https://lore.kernel.org/lkml/20200622233854.10889-3-rcampbell@nvidia.com
Ralph Campbell (5):
nouveau: fix storing invalid ptes
mm/migrate: add a direction parameter to migrate_vma
mm/notifier: add migration invalidation type
nouveau/svm: use the new migration invalidation
mm/hmm/test: use the new migration invalidation
arch/powerpc/kvm/book3s_hv_uvmem.c | 2 ++
drivers/gpu/drm/nouveau/nouveau_dmem.c | 13 ++++++--
drivers/gpu/drm/nouveau/nouveau_svm.c | 10 +++++-
drivers/gpu/drm/nouveau/nouveau_svm.h | 1 +
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 13 +++++---
include/linux/migrate.h | 12 +++++--
include/linux/mmu_notifier.h | 7 ++++
lib/test_hmm.c | 33 +++++++++++--------
mm/migrate.c | 13 ++++++--
9 files changed, 77 insertions(+), 27 deletions(-)
--
2.20.1
The goal for this series is to introduce the hmm_pfn_to_map_order()
function. This allows a device driver to know that a given 4K PFN is
actually mapped by the CPU using a larger sized CPU page table entry and
therefore the device driver can safely map system memory using larger
device MMU PTEs.
The series is based on 5.8.0-rc3 and is intended for Jason Gunthorpe's
hmm tree. These were originally part of a larger series:
https://lore.kernel.org/linux-mm/20200619215649.32297-1-rcampbell@nvidia.co…
Changes in v3:
Replaced the HMM_PFN_P[MU]D flags with hmm_pfn_to_map_order() to
indicate the size of the CPU mapping.
Changes in v2:
Make the hmm_range_fault() API changes into a separate series and add
two output flags for PMD/PUD instead of a single compund page flag as
suggested by Jason Gunthorpe.
Make the nouveau page table changes a separate patch as suggested by
Ben Skeggs.
Only add support for 2MB nouveau mappings initially since changing the
1:1 CPU/GPU page table size assumptions requires a bigger set of changes.
Rebase to 5.8.0-rc3.
Ralph Campbell (5):
nouveau/hmm: fault one page at a time
mm/hmm: add hmm_mapping order
nouveau: fix mapping 2MB sysmem pages
nouveau/hmm: support mapping large sysmem pages
hmm: add tests for HMM_PFN_PMD flag
drivers/gpu/drm/nouveau/nouveau_svm.c | 236 ++++++++----------
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 5 +-
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 82 ++++++
include/linux/hmm.h | 24 +-
lib/test_hmm.c | 4 +
lib/test_hmm_uapi.h | 4 +
mm/hmm.c | 14 +-
tools/testing/selftests/vm/hmm-tests.c | 76 ++++++
8 files changed, 299 insertions(+), 146 deletions(-)
--
2.20.1
A simple optimization for migrate_vma_*() when the source vma is not an
anonymous vma and a new test case to exercise it.
This is based on linux-mm and is for Andrew Morton's tree.
Changes in v2:
Do the same check for vma_is_anonymous() for pte_none().
Don't increment cpages if the page isn't migrating.
Ralph Campbell (2):
mm/migrate: optimize migrate_vma_setup() for holes
mm/migrate: add migrate-shared test for migrate_vma_*()
mm/migrate.c | 16 ++++++++++--
tools/testing/selftests/vm/hmm-tests.c | 35 ++++++++++++++++++++++++++
2 files changed, 49 insertions(+), 2 deletions(-)
--
2.20.1
A simple optimization for migrate_vma_*() when the source vma is not an
anonymous vma and a new test case to exercise it.
This is based on linux-mm and is for Andrew Morton's tree.
Ralph Campbell (2):
mm/migrate: optimize migrate_vma_setup() for holes
mm/migrate: add migrate-shared test for migrate_vma_*()
mm/migrate.c | 6 ++++-
tools/testing/selftests/vm/hmm-tests.c | 35 ++++++++++++++++++++++++++
2 files changed, 40 insertions(+), 1 deletion(-)
--
2.20.1
Hi,
This expands the seccomp selftest to poke a architectural behavior corner
that Keno Fischer noticed[1]. In the process, I took the opportunity
to do the kselftest harness variant refactoring I'd been meaning to do,
which made adding this test much nicer.
I'd prefer this went via the seccomp tree, as it builds on top of the
other recent seccomp feature addition tests. Testing and reviews are
welcome! :)
Thanks,
-Kees
[1] https://lore.kernel.org/lkml/CABV8kRxA9mXPZwtYrjbAfOfFewhABHddipccgk-LQJO+Z…
Kees Cook (3):
selftests/harness: Clean up kern-doc for fixtures
selftests/seccomp: Refactor to use fixture variants
selftests/seccomp: Check ENOSYS under tracing
tools/testing/selftests/kselftest_harness.h | 15 +-
tools/testing/selftests/seccomp/seccomp_bpf.c | 217 ++++++------------
2 files changed, 72 insertions(+), 160 deletions(-)
--
2.25.1
On 7/9/20 9:07 AM, Andy Lutomirski wrote:
> On Thu, Jul 9, 2020 at 8:56 AM Dave Hansen <dave.hansen(a)intel.com> wrote:
>> On 7/9/20 8:44 AM, Andersen, John wrote:
>>> Bits which are allowed to be pinned default to WP for CR0 and SMEP,
>>> SMAP, and UMIP for CR4.
>> I think it also makes sense to have FSGSBASE in this set.
>>
>> I know it hasn't been tested, but I think we should do the legwork to
>> test it. If not in this set, can we agree that it's a logical next step?
> I have no objection to pinning FSGSBASE, but is there a clear
> description of the threat model that this whole series is meant to
> address? The idea is to provide a degree of protection against an
> attacker who is able to convince a guest kernel to write something
> inappropriate to CR4, right? How realistic is this?
If a quick search can find this:
> https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-…
I'd pretty confident that the guys doing actual bad things have it in
their toolbox too.
Direct stderr to subprocess.STDOUT so error messages get included in the
subprocess.CalledProcessError exceptions output field. This results in
more meaningful error messages for the user.
This is already being done in the make_allyesconfig method. Do the same
for make_mrproper, make_olddefconfig, and make methods.
With this, failures on unclean trees [1] will give users an error
message that includes:
"The source tree is not clean, please run 'make ARCH=um mrproper'"
[1] https://bugzilla.kernel.org/show_bug.cgi?id=205219
Signed-off-by: Will Chen <chenwi(a)google.com>
---
tools/testing/kunit/kunit_kernel.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/kunit/kunit_kernel.py b/tools/testing/kunit/kunit_kernel.py
index 63dbda2d029f..e20e2056cb38 100644
--- a/tools/testing/kunit/kunit_kernel.py
+++ b/tools/testing/kunit/kunit_kernel.py
@@ -34,7 +34,7 @@ class LinuxSourceTreeOperations(object):
def make_mrproper(self):
try:
- subprocess.check_output(['make', 'mrproper'])
+ subprocess.check_output(['make', 'mrproper'], stderr=subprocess.STDOUT)
except OSError as e:
raise ConfigError('Could not call make command: ' + e)
except subprocess.CalledProcessError as e:
@@ -47,7 +47,7 @@ class LinuxSourceTreeOperations(object):
if build_dir:
command += ['O=' + build_dir]
try:
- subprocess.check_output(command, stderr=subprocess.PIPE)
+ subprocess.check_output(command, stderr=subprocess.STDOUT)
except OSError as e:
raise ConfigError('Could not call make command: ' + e)
except subprocess.CalledProcessError as e:
@@ -77,7 +77,7 @@ class LinuxSourceTreeOperations(object):
if build_dir:
command += ['O=' + build_dir]
try:
- subprocess.check_output(command)
+ subprocess.check_output(command, stderr=subprocess.STDOUT)
except OSError as e:
raise BuildError('Could not call execute make: ' + e)
except subprocess.CalledProcessError as e:
--
2.27.0.383.g050319c2ae-goog
The paravirtualized CR pinning patchset is a strengthened version of
existing control registers pinning for paravritualized guests. It
protects KVM guests from ROP based attacks which attempt to disable key
security features. Virtualized Linux guests such as Kata Containers, AWS
Lambda, and Chromos Termina will get this protection enabled by default
when they update their kernel / configs. Using virtualization allows us
to provide a stronger version of a proven exploit mitigation technique.
We’ve patched KVM to create 6 new KVM specific MSRs used to query which
bits may be pinned, and to set which bits are pinned high or low in
control registers 0 and 4. Linux guest support was added so that
non-kexec guests will be able to take advantage of this strengthened
protection by default. A plan for enabling guests with kexec is proposed
in this cover letter. As part of that plan, we add a command line flag
that allows users to opt-in to the protection on boot if they have kexec
built into their kernel, effectively opting out of kexec support.
Hibernation and suspend to ram were enabled by updating the location
where bits in control register 4 were saved to and restored from. The
work also includes minor patches for QEMU to ensure reboot works by
clearing the added MSRs and exposing the new CPUID feature bit. There is
one SMM related selftest added in this patchset and another patch for
kvm-unit-tests that will be sent separately.
Thank you to Sean and Drew who reviewed v2, to Boris, Paolo, Andy, and
Liran who reviewed v1, and to Sean, Dave, Kristen, and Rick who've
provided feedback throughout. I appreciate your time spent reviewing and
feedback.
Here are the previous RFC versions of this patchset for reference
RFC v2: https://lkml.org/lkml/2020/2/18/1162
RFC v1: https://lkml.org/lkml/2019/12/24/380
=== High level overview of the changes ===
- A CPUID feature bit as well as MSRs were added to KVM. Guests can use
the CPUID feature bit to determine if MSRs are available. Reading the
first 2 MSRs returns the bits which may be pinned for CR0/4
respectively. The next 4 MSRs are writeable and allow the guest and
host userspace to set which bits are pinned low or pinned high for
CR0/4.
- Hibernation and suspend-to-RAM are supported. This was done by
updating mmu_cr4_features on feature identification of the boot CPU.
As such, mmu_cr4_features is no longer read only after init.
- CPU hotplug is supported. Pinning is per vCPU. When running as a guest
pinning is requested after CPU identification for non-boot CPUs. The
boot CPU requests pinning a directly after existing pinning is setup.
- Nested virtualization is supported. SVM / VMX restore pinned bits on
VM-Exit if they had been unset in the host VMCB / VMCS.
- As suggested by Sean, unpinning of pinned bits on return from SMM due
to modification of SMRAM will cause an unhandleable emulation fault
resulting in termination of the guest.
- kexec support is still pending, since the plan is a bit long it's been
moved to the end of the cover letter. It talks about the decision to
make a command line parameter, why we opt in to pinning (and
effectively out of kexec). Being that those changes wouldn't be
localized to KVM (and this patchset is on top of kvm/next).
- As Paolo requested, a patch will be sent immediately following this
patchset for kvm-unit-tests with the unit tests for general
functionality. selftests are included for SMM specific functionality.
=== Chanages since RFCv2 ===
- Related to Drew's comments
- Used linux/stringify.h in selftests
- Added comments on why we don't use GUEST_* due to SMM trickiness.
We opt not to use GUEST_SYNC() because we also have to make a sync call
from SMM. As such, the address of the ucall struct we'd need to pass isn't
something we can put into the machine code in a maintainable way. At least
so far as I could tell.
- Related to Sean's comments
- Allowed pinning bits high or low rather than just high
- Cleaner code path for guest and host when writing to MSRs
- Didn't use read modify write behavior due to that requiring changes to
selftest save restore code which made me suspect that there might be
issues with other VMMs. The issue was because we read CR0/4 in the RWM
operation on the MSR, we must do KVM_SET_REGS before KVM_SET_MSRS, we also
had to call KVM_SET_SREGS and add checks for if we're in SMM or not. This
made it a bit more messy overall so I went with the first approach Sean
suggested where we just have pin high/low semantics.
- If the guest writes values to the allowed MSRs that are not the correct
value the wrmsr fails.
- If SMRAM modification would result in unpinning bits we bail with
X86EMUL_UNHANDLEABLE
- Added silent restoration of pinned bits for SVM and VMX when they may have
been modified in VMCB / VMCS. This didn't seem like a place were we'd want
to inject a fault, please let me know if we should.
=== Description of changes and rational ===
Paravirtualized Control Register pinning is a strengthened version of
existing protections on the Write Protect, Supervisor Mode Execution /
Access Protection, and User-Mode Instruction Prevention bits. The
existing protections prevent native_write_cr*() functions from writing
values which disable those bits. This patchset prevents any guest
writes to control registers from disabling pinned bits, not just writes
from native_write_cr*(). This stops attackers within the guest from
using ROP to disable protection bits.
https://web.archive.org/web/20171029060939/http://www.blackbunny.io/linux-k…
The protection is implemented by adding MSRs to KVM which contain the
bits that are allowed to be pinned, and the bits which are pinned. The
guest or userspace can enable bit pinning by reading MSRs to check
which bits are allowed to be pinned, and then writing MSRs to set which
bits they want pinned.
Other hypervisors such as HyperV have implemented similar protections
for Control Registers and MSRs; which security researchers have found
effective.
https://www.abatchy.com/2018/01/kernel-exploitation-4
We add a CR pin feature bit to the KVM cpuid, read only MSRs which
guests use to identify which bits they may request be pinned, and CR
pinned low/high MSRs which contain the pinned bits. Guests can request
that KVM pin bits within control register 0 or 4 via the CR pinned MSRs.
Writes to the MSRs fail if they include bits that aren't allowed to be
pinned. Host userspace may clear or modify pinned bits at any time. Once
pinned bits are set, the guest may pin more allowed bits, but may never
clear pinned bits.
In the event that the guest vCPU attempts to disable any of the pinned
bits, the vCPU that issued the write is sent a general protection
fault, and the register is left unchanged.
When running with KVM guest support and paravirtualized CR pinning
enabled, paravirtualized and existing pinning are setup at the same
point on the boot CPU. Non-boot CPUs setup pinning upon identification.
Pinning is not active when running in SMM. Entering SMM disables pinned
bits. Writes to control registers within SMM would therefore trigger
general protection faults if pinning was enforced. Upon exit from SMM,
SMRAM is modified to ensure the values of CR0/4 that will be restored
contain the correct values for pinned bits. CR0/4 values are then
restored from SMRAM as usual.
When running with nested virtualization, should pinned bits be cleared
from host VMCS / VMCB, on VM-Exit, they will be silently restored.
Should userspace expose the CR pining CPUID feature bit, it must zero
CR pinned MSRs on reboot. If it does not, it runs the risk of having
the guest enable pinning and subsequently cause general protection
faults on next boot due to early boot code setting control registers to
values which do not contain the pinned bits.
Hibernation to disk and suspend-to-RAM are supported. identify_cpu was
updated to ensure SMEP/SMAP/UMIP are present in mmu_cr4_features. This
is necessary to ensure protections stay active during hibernation image
restoration.
Guests using the kexec system call currently do not support
paravirtualized control register pinning. This is due to early boot
code writing known good values to control registers, these values do
not contain the protected bits. This is due to CPU feature
identification being done at a later time, when the kernel properly
checks if it can enable protections. As such, the pv_cr_pin command
line option has been added which instructs the kernel to disable kexec
in favor of enabling paravirtualized control register pinning.
crashkernel is also disabled when the pv_cr_pin parameter is specified
due to its reliance on kexec.
When we make kexec compatible, we will still need a way for a kernel
with support to know if the kernel it is attempting to load has
support. If a kernel with this enabled attempts to kexec a kernel where
this is not supported, it would trigger a fault almost immediately.
Liran suggested adding a section to the built image acting as a flag to
signify support for being kexec'd by a kernel with pinning enabled.
Should that approach be implemented, it is likely that the command line
flag (pv_cr_pin) would still be desired for some deprecation period. We
wouldn't want the default behavior to change from being able to kexec
older kernels to not being able to, as this might break some users
workflows. Since we require that the user opt-in to break kexec we've
held off on attempting to fix kexec in this patchset. This way no one
sees any behavior they are not explicitly opting in to.
Security conscious kernel configurations disable kexec already, per
KSPP guidelines. Projects such as Kata Containers, AWS Lambda, ChromeOS
Termina, and others using KVM to virtualize Linux will benefit from
this protection without the need to specify pv_cr_pin on the command
line.
Pinning of sensitive CR bits has already been implemented to protect
against exploits directly calling native_write_cr*(). The current
protection cannot stop ROP attacks which jump directly to a MOV CR
instruction. Guests running with paravirtualized CR pinning are now
protected against the use of ROP to disable CR bits. The same bits that
are being pinned natively may be pinned via the CR pinned MSRs. These
bits are WP in CR0, and SMEP, SMAP, and UMIP in CR4.
Future patches could implement similar MSRs to protect bits in MSRs.
The NXE bit of the EFER MSR is a prime candidate.
=== Plan for kexec support ===
Andy's suggestion of a boot option has been incorporated as the
pv_cr_pin command line option. Boris mentioned that short-term
solutions become immutable. However, for the reasons outlined below
we need a way for the user to opt-in to pinning over kexec if both
are compiled in, and the command line parameter seems to be a good
way to do that. Liran's proposed solution of a flag within the ELF
would allow us to identify which kernels have support is assumed to
be implemented in the following scenarios.
We then have the following cases (without the addition of pv_cr_pin):
- Kernel running without pinning enabled kexecs kernel with pinning.
- Loaded kernel has kexec
- Do not enable pinning
- Loaded kernel lacks kexec
- Enable pinning
- Kernel running with pinning enabled kexecs kernel with pinning (as
identified by ELF addition).
- Okay
- Kernel running with pinning enabled kexecs kernel without pinning
(as identified by lack of ELF addition).
- User is presented with an error saying that they may not kexec
a kernel without pinning support.
With the addition of pv_cr_pin we have the following situations:
- Kernel running without pinning enabled kexecs kernel with pinning.
- Loaded kernel has kexec
- pv_cr_pin command line parameter present for new kernel
- Enable pinning
- pv_cr_pin command line parameter not present for new kernel
- Do not enable pinning
- Loaded kernel lacks kexec
- Enable pinning
- Kernel running with pinning enabled kexecs kernel with pinning (as
identified by ELF addition).
- Okay
- Kernel running with kexec and pinning enabled (opt-in via pv_cr_pin)
kexecs kernel without pinning (as identified by lack of ELF addition).
- User is presented with an error saying that they have opted
into pinning support and may not kexec a kernel without pinning
support.
Without the command line parameter I'm not sure how we could preserve
users workflows which might rely on kexecing older kernels (ones
which wouldn't have support). I see the benefit here being that users
have to opt-in to the possibility of breaking their workflow, via
their addition of the pv_cr_pin command line flag. Which could of
course also be called nokexec. A deprecation period could then be
chosen where eventually pinning takes preference over kexec and users
are presented with the error if they try to kexec an older kernel.
Input on this would be much appreciated, as well as if this is the
best way to handle things or if there's another way that would be
preferred. This is just what we were able to come up with to ensure
users didn't get anything broken they didn't agree to have broken.
Thanks,
John
John Andersen (4):
X86: Update mmu_cr4_features during feature identification
KVM: x86: Introduce paravirt feature CR0/CR4 pinning
selftests: kvm: add test for CR pinning with SMM
X86: Use KVM CR pin MSRs
.../admin-guide/kernel-parameters.txt | 11 +
Documentation/virt/kvm/msr.rst | 53 +++++
arch/x86/Kconfig | 10 +
arch/x86/include/asm/kvm_host.h | 7 +
arch/x86/include/asm/kvm_para.h | 28 +++
arch/x86/include/uapi/asm/kvm_para.h | 7 +
arch/x86/kernel/cpu/common.c | 11 +-
arch/x86/kernel/kvm.c | 39 ++++
arch/x86/kernel/setup.c | 12 +-
arch/x86/kvm/cpuid.c | 3 +-
arch/x86/kvm/emulate.c | 3 +-
arch/x86/kvm/kvm_emulate.h | 2 +-
arch/x86/kvm/svm/nested.c | 11 +-
arch/x86/kvm/vmx/nested.c | 10 +-
arch/x86/kvm/x86.c | 106 ++++++++-
tools/testing/selftests/kvm/.gitignore | 1 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/include/x86_64/processor.h | 13 ++
.../selftests/kvm/x86_64/smm_cr_pin_test.c | 207 ++++++++++++++++++
19 files changed, 521 insertions(+), 14 deletions(-)
create mode 100644 tools/testing/selftests/kvm/x86_64/smm_cr_pin_test.c
base-commit: 49b3deaad3452217d62dbd78da8df24eb0c7e169
--
2.21.0
Hello!
v6:
- fix missing fput()
- API name change: s/fd_install_received/receive_fd/
v5: https://lore.kernel.org/lkml/20200617220327.3731559-1-keescook@chromium.org/
This continues the thread-merge between [1] and [2]. tl;dr: add a way for
a seccomp user_notif process manager to inject files into the managed
process in order to handle emulation of various fd-returning syscalls
across security boundaries. Containers folks and Chrome are in need
of the feature, and investigating this solution uncovered (and fixed)
implementation issues with existing file sending routines.
I intend to carry this in the for-next/seccomp tree, unless someone
has objections. :) Please review and test!
-Kees
[1] https://lore.kernel.org/lkml/20200603011044.7972-1-sargun@sargun.me/
[2] https://lore.kernel.org/lkml/20200610045214.1175600-1-keescook@chromium.org/
Kees Cook (5):
net/scm: Regularize compat handling of scm_detach_fds()
fs: Move __scm_install_fd() to __receive_fd()
fs: Add receive_fd() wrapper for __receive_fd()
pidfd: Replace open-coded partial receive_fd()
fs: Expand __receive_fd() to accept existing fd
Sargun Dhillon (2):
seccomp: Introduce addfd ioctl to seccomp user notifier
selftests/seccomp: Test SECCOMP_IOCTL_NOTIF_ADDFD
fs/file.c | 67 +++++
include/linux/file.h | 19 ++
include/linux/net.h | 9 +
include/uapi/linux/seccomp.h | 22 ++
kernel/pid.c | 13 +-
kernel/seccomp.c | 172 ++++++++++++-
net/compat.c | 55 ++---
net/core/scm.c | 50 +---
tools/testing/selftests/seccomp/seccomp_bpf.c | 229 ++++++++++++++++++
9 files changed, 554 insertions(+), 82 deletions(-)
--
2.25.1
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster(a)al2klimov.de>
---
Continuing my work started at 93431e0607e5.
See also: git log --oneline '--author=Alexander A. Klimov <grandmaster(a)al2klimov.de>' v5.7..master
(Actually letting a shell for loop submit all this stuff for me.)
If there are any URLs to be removed completely or at least not HTTPSified:
Just clearly say so and I'll *undo my change*.
See also: https://lkml.org/lkml/2020/6/27/64
If there are any valid, but yet not changed URLs:
See: https://lkml.org/lkml/2020/6/26/837
If you apply the patch, please let me know.
tools/testing/selftests/kmod/kmod.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kmod/kmod.sh b/tools/testing/selftests/kmod/kmod.sh
index 3702dbcc90a7..84409020a40f 100755
--- a/tools/testing/selftests/kmod/kmod.sh
+++ b/tools/testing/selftests/kmod/kmod.sh
@@ -128,7 +128,7 @@ test_reqs()
if [[ $KMOD_VERSION -le 19 ]]; then
echo "$0: You need at least kmod 20" >&2
echo "kmod <= 19 is buggy, for details see:" >&2
- echo "http://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/commit/libkmod/libkmo…" >&2
+ echo "https://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/commit/libkmod/libkm…" >&2
exit $ksft_skip
fi
--
2.27.0
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. And another request
to move existing kernel_read_file* functions to its own include file.
Changes from v9:
- add patch to move existing kernel_read_file* to its own include file
- driver fixes
Changes from v8:
- correct compilation error when CONFIG_FW_LOADER not defined
Changes from v7:
- 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 (9):
fs: move kernel_read_file* to its own include file
fs: introduce kernel_pread_file* support
firmware: add request_partial_firmware_into_buf
test_firmware: add partial read support for request_firmware_into_buf
firmware: test partial file reads of request_partial_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 | 80 +-
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 | 419 +++++
drivers/misc/bcm-vk/bcm_vk_dev.c | 1357 +++++++++++++++
drivers/misc/bcm-vk/bcm_vk_msg.c | 1504 +++++++++++++++++
drivers/misc/bcm-vk/bcm_vk_msg.h | 211 +++
drivers/misc/bcm-vk/bcm_vk_sg.c | 275 +++
drivers/misc/bcm-vk/bcm_vk_sg.h | 61 +
drivers/misc/bcm-vk/bcm_vk_tty.c | 352 ++++
fs/exec.c | 92 +-
include/linux/firmware.h | 12 +
include/linux/fs.h | 39 -
include/linux/ima.h | 1 +
include/linux/kernel_read_file.h | 69 +
include/linux/security.h | 1 +
include/uapi/linux/misc/bcm_vk.h | 99 ++
kernel/kexec_file.c | 1 +
kernel/module.c | 1 +
lib/test_firmware.c | 154 +-
security/integrity/digsig.c | 1 +
security/integrity/ima/ima_fs.c | 1 +
security/integrity/ima/ima_main.c | 25 +-
security/integrity/ima/ima_policy.c | 1 +
security/loadpin/loadpin.c | 1 +
security/security.c | 1 +
security/selinux/hooks.c | 1 +
.../selftests/firmware/fw_filesystem.sh | 80 +
32 files changed, 4802 insertions(+), 91 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/linux/kernel_read_file.h
create mode 100644 include/uapi/linux/misc/bcm_vk.h
--
2.17.1
On Mon, Jul 06, 2020 at 04:23:07PM -0700, Scott Branden wrote:
> Add Broadcom VK driver offload engine.
> This driver interfaces to the VK PCIe offload engine to perform
> should offload functions as video transcoding on multiple streams
> in parallel. VK device is booted from files loaded using
> request_firmware_into_buf mechanism. After booted card status is updated
> and messages can then be sent to the card.
> Such messages contain scatter gather list of addresses
> to pull data from the host to perform operations on.
>
> Signed-off-by: Scott Branden <scott.branden(a)broadcom.com>
> Signed-off-by: Desmond Yan <desmond.yan(a)broadcom.com>
nit: your S-o-b chain doesn't make sense (I would expect you at the end
since you're sending it and showing as the Author). Is it Co-developed-by?
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when…
> [...]
> +
> + max_buf = SZ_4M;
> + bufp = dma_alloc_coherent(dev,
> + max_buf,
> + &boot_dma_addr, GFP_KERNEL);
> + if (!bufp) {
> + dev_err(dev, "Error allocating 0x%zx\n", max_buf);
> + ret = -ENOMEM;
> + goto err_buf_out;
> + }
> +
> + bcm_vk_buf_notify(vk, bufp, boot_dma_addr, max_buf);
> + } else {
> + dev_err(dev, "Error invalid image type 0x%x\n", load_type);
> + ret = -EINVAL;
> + goto err_buf_out;
> + }
> +
> + ret = request_partial_firmware_into_buf(&fw, filename, dev,
> + bufp, max_buf, 0);
Unless I don't understand what's happening here, this needs to be
reordered if you're going to keep Mimi happy and disallow the device
being able to see the firmware before it has been verified. (i.e. please
load the firmware before mapping DMA across the buffer.)
--
Kees Cook
From: Uriel Guajardo <urielguajardo(a)google.com>
With these patches, KUnit can access and manually run kmemleak in every test
case. Any errors caught by kmemleak will cause the KUnit test to fail.
This patchset relies on "kunit: KASAN integration", which places the
currently running kunit test in task_struct. [1]
[1] https://lore.kernel.org/linux-kselftest/20200606040349.246780-2-davidgow@go…
Uriel Guajardo (2):
kunit: support kunit failures from debugging tools
kunit: kmemleak integration
include/kunit/test-bug.h | 15 +++++++++++++
include/kunit/test.h | 1 +
include/linux/kmemleak.h | 11 ++++++++++
lib/Kconfig.debug | 26 +++++++++++++++++++++++
lib/kunit/test.c | 46 +++++++++++++++++++++++++++++++++++-----
mm/kmemleak.c | 27 +++++++++++++++++------
6 files changed, 115 insertions(+), 11 deletions(-)
create mode 100644 include/kunit/test-bug.h
--
2.27.0.212.ge8ba1cc988-goog
The patch series introduces a mechanism to measure wakeup latency for
IPI and timer based interrupts
The motivation behind this series is to find significant deviations
behind advertised latency and resisdency values
To achieve this, we introduce a kernel module and expose its control
knobs through the debugfs interface that the selftests can engage with.
The kernel module provides the following interfaces within
/sys/kernel/debug/latency_test/ for,
1. IPI test:
ipi_cpu_dest # Destination CPU for the IPI
ipi_cpu_src # Origin of the IPI
ipi_latency_ns # Measured latency time in ns
2. Timeout test:
timeout_cpu_src # CPU on which the timer to be queued
timeout_expected_ns # Timer duration
timeout_diff_ns # Difference of actual duration vs expected timer
To include the module, check option and include as module
kernel hacking -> Cpuidle latency selftests
The selftest inserts the module, disables all the idle states and
enables them one by one testing:
1. Keeping source CPU constant, iterates through all the CPUS measuring
IPI latency for baseline (CPU is busy with "yes" workload) and the
when the CPU is at rest
2. Iterating through all the CPUs, sending expected timer durations to
be equivalent to the residency of the the deepest idle state
enabled and extracting the difference in time between the time of
wakeup and the expected timer duration
Usage
-----
Can be used in conjuction to the rest of the selftests.
Default Output location in: tools/testing/cpuidle/cpuidle.log
To run this test specifically:
$ make -C tools/testing/selftests TARGETS="cpuidle" run_tests
There are a few optinal arguments too that the script can take
[-h <help>]
[-m <location of the module>]
[-o <location of the output>]
Sample output snippet
---------------------
--IPI Latency Test---
---Enabling state: 0---
SRC_CPU DEST_CPU Base_IPI_Latency(ns) IPI_Latency(ns)
0 0 328 291
0 1 1500 1071
0 2 1070 1062
0 3 1557 1668
. . . .
Expected IPI latency(ns): 1000
Baseline Average IPI latency(ns): 1113
Observed Average IPI latency(ns): 1023
--Timeout Latency Test--
---Enabling state: 0---
Wakeup_src Baseline_delay(ns) Delay(ns)
0 3134 2128
1 2275 2107
2 2222 2198
3 2421 2325
. . . .
Expected timeout(ns): 200
Baseline Average timeout diff(ns): 2513
Observed Average timeout diff(ns): 2189
Pratik Rajesh Sampat (2):
cpuidle: Trace IPI based and timer based wakeup latency from idle
states
selftest/cpuidle: Add support for cpuidle latency measurement
drivers/cpuidle/Makefile | 1 +
drivers/cpuidle/test-cpuidle_latency.c | 150 +++++++++++++
lib/Kconfig.debug | 10 +
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/cpuidle/Makefile | 6 +
tools/testing/selftests/cpuidle/cpuidle.sh | 240 +++++++++++++++++++++
tools/testing/selftests/cpuidle/settings | 1 +
7 files changed, 409 insertions(+)
create mode 100644 drivers/cpuidle/test-cpuidle_latency.c
create mode 100644 tools/testing/selftests/cpuidle/Makefile
create mode 100755 tools/testing/selftests/cpuidle/cpuidle.sh
create mode 100644 tools/testing/selftests/cpuidle/settings
--
2.25.4
Calling ksft_exit_* results in executing fewer tests than planned, which
is wrong for ksft_exit_skip or suboptimal (because it results in a bail
out) for ksft_exit_fail_msg.
Using ksft_test_result_skip instead skips only one test and lets the
test plan proceed as promised by ksft_set_plan.
Paolo
v3->v4: remove useless initialization
Paolo Bonzini (2):
selftests: pidfd: do not use ksft_exit_skip after ksft_set_plan
selftests: pidfd: skip test if unshare fails with EPERM
tools/testing/selftests/pidfd/pidfd_test.c | 55 ++++++++++++++++++----
1 file changed, 46 insertions(+), 9 deletions(-)
--
2.26.2
Calling ksft_exit_* results in executing fewer tests than planned, which
is wrong for ksft_exit_skip or suboptimal (because it results in a bail
out) for ksft_exit_fail_msg.
Using ksft_test_result_skip instead skips only one test and lets the
test plan proceed as promised by ksft_set_plan.
Paolo
Paolo Bonzini (2):
selftests: pidfd: do not use ksft_exit_skip after ksft_set_plan
selftests: pidfd: skip test if unshare fails with EPERM
tools/testing/selftests/pidfd/pidfd_test.c | 55 ++++++++++++++++++----
1 file changed, 46 insertions(+), 9 deletions(-)
--
2.26.2
From: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
commit 5be206eaac9a68992fc3b06fb5dd5634e323de86 upstream.
The reverted commit illegitly uses tpm2-tools. External dependencies are
absolutely forbidden from these tests. There is also the problem that
clearing is not necessarily wanted behavior if the test/target computer is
not used only solely for testing.
Fixes: a9920d3bad40 ("tpm: selftest: cleanup after unseal with wrong auth/policy test")
Cc: Tadeusz Struk <tadeusz.struk(a)intel.com>
Cc: stable(a)vger.kernel.org
Cc: linux-integrity(a)vger.kernel.org
Cc: linux-kselftest(a)vger.kernel.org
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/testing/selftests/tpm2/test_smoke.sh | 5 -----
1 file changed, 5 deletions(-)
--- a/tools/testing/selftests/tpm2/test_smoke.sh
+++ b/tools/testing/selftests/tpm2/test_smoke.sh
@@ -3,8 +3,3 @@
python -m unittest -v tpm2_tests.SmokeTest
python -m unittest -v tpm2_tests.AsyncTest
-
-CLEAR_CMD=$(which tpm2_clear)
-if [ -n $CLEAR_CMD ]; then
- tpm2_clear -T device
-fi
This is v2 of the patch to fix TAP output for skipped tests. I noticed
and fixed two other occurrences of "not ok ... # SKIP" which according
to the TAP specification should be marked as "ok ... # SKIP" instead.
Unfortunately, closer analysis showed ksft_exit_skip to be a badly
misused API. It should be used when the remainder of the testcase
is being skipped, but TAP only supports this before the test plan
has been emitted (in which case you're supposed to print "1..0 # SKIP".
Therefore, in patch 1 I'm mostly trying to do something sensible,
printing "1..0 # SKIP" is possible or "ok ... # SKIP" if not (which is
no worse than what was doing before). The remaining five patches
show what needs to be done in order to avoid ksft_exit_skip misuse;
while working on them I found other bugs that I've fixed at the same
time; see patch 2 for an example.
In the interest of full disclosure, I won't be able to do more cleanups
of ksft_exit_skip callers. However, I have fixed all those that did
call ksft_set_plan() as those at least try to produce TAP output.
Paolo
Paolo Bonzini (6):
kselftest: fix TAP output for skipped tests
selftests: breakpoints: fix computation of test plan
selftests: breakpoints: do not use ksft_exit_skip after ksft_set_plan
selftests: pidfd: do not use ksft_exit_skip after ksft_set_plan
selftests: sigaltstack: do not use ksft_exit_skip after ksft_set_plan
selftests: sync_test: do not use ksft_exit_skip after ksft_set_plan
.../breakpoints/step_after_suspend_test.c | 53 +++++++++++--------
tools/testing/selftests/kselftest.h | 28 +++++++---
tools/testing/selftests/kselftest/runner.sh | 2 +-
tools/testing/selftests/pidfd/pidfd_test.c | 39 +++++++++++---
tools/testing/selftests/sigaltstack/sas.c | 4 +-
tools/testing/selftests/sync/sync_test.c | 2 +-
6 files changed, 87 insertions(+), 41 deletions(-)
--
2.26.2
The --defconfig option in kunit_tool was removed in [1], but the getting
started and kunit_tool documentation still encouraged its use. Update
those documents to reflect that it's no-longer required, and is the
default behaviour if no .kunitconfig is found.
Also update a couple of places where .kunitconfig is still referred to
as kunitconfig (this was changed in [2]).
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/c…
[2]:
https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/c…
Signed-off-by: David Gow <davidgow(a)google.com>
---
Documentation/dev-tools/kunit/kunit-tool.rst | 17 +++++------------
Documentation/dev-tools/kunit/start.rst | 2 +-
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/Documentation/dev-tools/kunit/kunit-tool.rst b/Documentation/dev-tools/kunit/kunit-tool.rst
index 949af2da81e5..29ae2fee8123 100644
--- a/Documentation/dev-tools/kunit/kunit-tool.rst
+++ b/Documentation/dev-tools/kunit/kunit-tool.rst
@@ -19,13 +19,13 @@ compiles the kernel as a standalone Linux executable that can be run like any
other program directly inside of a host operating system. To be clear, it does
not require any virtualization support: it is just a regular program.
-What is a kunitconfig?
-======================
+What is a .kunitconfig?
+=======================
It's just a defconfig that kunit_tool looks for in the base directory.
kunit_tool uses it to generate a .config as you might expect. In addition, it
verifies that the generated .config contains the CONFIG options in the
-kunitconfig; the reason it does this is so that it is easy to be sure that a
+.kunitconfig; the reason it does this is so that it is easy to be sure that a
CONFIG that enables a test actually ends up in the .config.
How do I use kunit_tool?
@@ -46,16 +46,9 @@ However, you most likely want to use it with the following options:
- ``--timeout`` sets a maximum amount of time to allow tests to run.
- ``--jobs`` sets the number of threads to use to build the kernel.
-If you just want to use the defconfig that ships with the kernel, you can
-append the ``--defconfig`` flag as well:
-
-.. code-block:: bash
-
- ./tools/testing/kunit/kunit.py run --timeout=30 --jobs=`nproc --all` --defconfig
-
.. note::
- This command is particularly helpful for getting started because it
- just works. No kunitconfig needs to be present.
+ This command will work even without a .kunitconfig file: if no
+ .kunitconfig is present, a default one will be used instead.
For a list of all the flags supported by kunit_tool, you can run:
diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst
index bb112cf70624..d23385e3e159 100644
--- a/Documentation/dev-tools/kunit/start.rst
+++ b/Documentation/dev-tools/kunit/start.rst
@@ -18,7 +18,7 @@ The wrapper can be run with:
.. code-block:: bash
- ./tools/testing/kunit/kunit.py run --defconfig
+ ./tools/testing/kunit/kunit.py run
For more information on this wrapper (also called kunit_tool) check out the
:doc:`kunit-tool` page.
--
2.27.0.212.ge8ba1cc988-goog
From: Uriel Guajardo <urielguajardo(a)google.com>
With these patches, KUnit can access and manually run kmemleak in every test
case. Any errors caught by kmemleak will cause the KUnit test to fail.
This patchset relies on "kunit: KASAN integration", which places the
currently running kunit test in task_struct. [1]
[1] https://lore.kernel.org/linux-kselftest/20200606040349.246780-2-davidgow@go…
Uriel Guajardo (2):
kunit: support kunit failures from debugging tools
kunit: kmemleak integration
include/kunit/test-bug.h | 15 +++++++++++++
include/kunit/test.h | 1 +
include/linux/kmemleak.h | 11 ++++++++++
lib/Kconfig.debug | 26 +++++++++++++++++++++++
lib/kunit/test.c | 46 +++++++++++++++++++++++++++++++++++-----
mm/kmemleak.c | 27 +++++++++++++++++------
6 files changed, 115 insertions(+), 11 deletions(-)
create mode 100644 include/kunit/test-bug.h
--
2.27.0.212.ge8ba1cc988-goog
When investigating performance issues that involve latency / loss /
reordering it is useful to have the pcap from the sender-side as it
allows to easier infer the state of the sender's congestion-control,
loss-recovery, etc.
Allow the selftests to capture a pcap on both sender and receiver so
that this information is not lost when reproducing.
This patch also improves the file names. Instead of:
ns4-5ee79a56-X4O6gS-ns3-5ee79a56-X4O6gS-MPTCP-MPTCP-10.0.3.1.pcap
We now have something like for the same test:
5ee79a56-X4O6gS-ns3-ns4-MPTCP-MPTCP-10.0.3.1-10030-connector.pcap
5ee79a56-X4O6gS-ns3-ns4-MPTCP-MPTCP-10.0.3.1-10030-listener.pcap
It was a connection from ns3 to ns4, better to start with ns3 then. The
port is also added, easier to find the trace we want.
Co-developed-by: Christoph Paasch <cpaasch(a)apple.com>
Signed-off-by: Christoph Paasch <cpaasch(a)apple.com>
Signed-off-by: Matthieu Baerts <matthieu.baerts(a)tessares.net>
---
tools/testing/selftests/net/mptcp/mptcp_connect.sh | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/net/mptcp/mptcp_connect.sh b/tools/testing/selftests/net/mptcp/mptcp_connect.sh
index 8f7145c413b9..c0589e071f20 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_connect.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_connect.sh
@@ -395,10 +395,14 @@ do_transfer()
capuser="-Z $SUDO_USER"
fi
- local capfile="${listener_ns}-${connector_ns}-${cl_proto}-${srv_proto}-${connect_addr}.pcap"
+ local capfile="${rndh}-${connector_ns:0:3}-${listener_ns:0:3}-${cl_proto}-${srv_proto}-${connect_addr}-${port}"
+ local capopt="-i any -s 65535 -B 32768 ${capuser}"
- ip netns exec ${listener_ns} tcpdump -i any -s 65535 -B 32768 $capuser -w $capfile > "$capout" 2>&1 &
- local cappid=$!
+ ip netns exec ${listener_ns} tcpdump ${capopt} -w "${capfile}-listener.pcap" >> "${capout}" 2>&1 &
+ local cappid_listener=$!
+
+ ip netns exec ${connector_ns} tcpdump ${capopt} -w "${capfile}-connector.pcap" >> "${capout}" 2>&1 &
+ local cappid_connector=$!
sleep 1
fi
@@ -423,7 +427,8 @@ do_transfer()
if $capture; then
sleep 1
- kill $cappid
+ kill ${cappid_listener}
+ kill ${cappid_connector}
fi
local duration
--
2.27.0
Hello!
v5:
- merge ioctl fixes into Sargun's patches directly
- adjust new API to avoid "ufd_required" argument
- drop general clean up patches now present in for-next/seccomp
v4: https://lore.kernel.org/lkml/20200616032524.460144-1-keescook@chromium.org/
This continues the thread-merge between [1] and [2]. tl;dr: add a way for
a seccomp user_notif process manager to inject files into the managed
process in order to handle emulation of various fd-returning syscalls
across security boundaries. Containers folks and Chrome are in need
of the feature, and investigating this solution uncovered (and fixed)
implementation issues with existing file sending routines.
I intend to carry this in the seccomp tree, unless someone has objections.
:) Please review and test!
-Kees
[1] https://lore.kernel.org/lkml/20200603011044.7972-1-sargun@sargun.me/
[2] https://lore.kernel.org/lkml/20200610045214.1175600-1-keescook@chromium.org/
Kees Cook (5):
net/scm: Regularize compat handling of scm_detach_fds()
fs: Move __scm_install_fd() to __fd_install_received()
fs: Add fd_install_received() wrapper for __fd_install_received()
pidfd: Replace open-coded partial fd_install_received()
fs: Expand __fd_install_received() to accept fd
Sargun Dhillon (2):
seccomp: Introduce addfd ioctl to seccomp user notifier
selftests/seccomp: Test SECCOMP_IOCTL_NOTIF_ADDFD
fs/file.c | 63 +++++
include/linux/file.h | 19 ++
include/uapi/linux/seccomp.h | 22 ++
kernel/pid.c | 11 +-
kernel/seccomp.c | 172 ++++++++++++-
net/compat.c | 55 ++---
net/core/scm.c | 50 +---
tools/testing/selftests/seccomp/seccomp_bpf.c | 229 ++++++++++++++++++
8 files changed, 540 insertions(+), 81 deletions(-)
--
2.25.1
Here is a tiny new syscall, readfile, that makes it simpler to read
small/medium sized files all in one shot, no need to do open/read/close.
This is especially helpful for tools that poke around in procfs or
sysfs, making a little bit of a less system load than before, especially
as syscall overheads go up over time due to various CPU bugs being
addressed.
There are 4 patches in this series, the first 3 are against the kernel
tree, adding the syscall logic, wiring up the syscall, and adding some
tests for it.
The last patch is agains the man-pages project, adding a tiny man page
to try to describe the new syscall.
Greg Kroah-Hartman (3):
readfile: implement readfile syscall
arch: wire up the readfile syscall
selftests: add readfile(2) selftests
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 +
arch/ia64/kernel/syscalls/syscall.tbl | 1 +
arch/m68k/kernel/syscalls/syscall.tbl | 1 +
arch/microblaze/kernel/syscalls/syscall.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n32.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n64.tbl | 1 +
arch/mips/kernel/syscalls/syscall_o32.tbl | 1 +
arch/parisc/kernel/syscalls/syscall.tbl | 1 +
arch/powerpc/kernel/syscalls/syscall.tbl | 1 +
arch/s390/kernel/syscalls/syscall.tbl | 1 +
arch/sh/kernel/syscalls/syscall.tbl | 1 +
arch/sparc/kernel/syscalls/syscall.tbl | 1 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
fs/open.c | 50 +++
include/linux/syscalls.h | 2 +
include/uapi/asm-generic/unistd.h | 4 +-
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/readfile/.gitignore | 3 +
tools/testing/selftests/readfile/Makefile | 7 +
tools/testing/selftests/readfile/readfile.c | 285 +++++++++++++++++
.../selftests/readfile/readfile_speed.c | 301 ++++++++++++++++++
26 files changed, 671 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/readfile/.gitignore
create mode 100644 tools/testing/selftests/readfile/Makefile
create mode 100644 tools/testing/selftests/readfile/readfile.c
create mode 100644 tools/testing/selftests/readfile/readfile_speed.c
--
2.27.0
Hi Linus,
Please pull the following Kselftest fixes update for Linux 5.8-rc4.
This kselftest fixes update for Linux 5.8-rc4 consists of tpm test
fixes from Jarkko Sakkinen.
diff is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68:
Linux 5.8-rc3 (2020-06-28 15:00:24 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-fixes-5.8-rc4
for you to fetch changes up to 377ff83083c953dd58c5a030b3c9b5b85d8cc727:
selftests: tpm: Use /bin/sh instead of /bin/bash (2020-06-29 14:19:38
-0600)
----------------------------------------------------------------
linux-kselftest-fixes-5.8-rc4
This kselftest fixes update for Linux 5.8-rc4 consists of tpm test
fixes from Jarkko Sakkinen.
----------------------------------------------------------------
Jarkko Sakkinen (3):
Revert "tpm: selftest: cleanup after unseal with wrong
auth/policy test"
selftests: tpm: Use 'test -e' instead of 'test -f'
selftests: tpm: Use /bin/sh instead of /bin/bash
tools/testing/selftests/tpm2/test_smoke.sh | 9 ++-------
tools/testing/selftests/tpm2/test_space.sh | 4 ++--
2 files changed, 4 insertions(+), 9 deletions(-)
----------------------------------------------------------------
Hi Linus,
Please pull the following Kunit fixes update for Linux 5.8-rc4.
This kunit fixes update for Linux 5.8-rc4 consists of fixes to build
and run-times failures. Also includes troubleshooting tips updates
to kunit user documentation.
These tips in the doc patch helped me with my test runs.
diff is included.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit 48778464bb7d346b47157d21ffde2af6b2d39110:
Linux 5.8-rc2 (2020-06-21 15:45:29 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-kunit-fixes-5.8-rc4
for you to fetch changes up to c63d2dd7e134ebddce4745c51f9572b3f0d92b26:
Documentation: kunit: Add some troubleshooting tips to the FAQ
(2020-06-26 14:29:55 -0600)
----------------------------------------------------------------
linux-kselftest-kunit-fixes-5.8-rc4
This kunit fixes update for Linux 5.8-rc4 consists of fixes to build
and run-times failures. Also includes troubleshooting tips updates
to kunit user documentation.
----------------------------------------------------------------
David Gow (2):
kunit: kunit_tool: Fix invalid result when build fails
Documentation: kunit: Add some troubleshooting tips to the FAQ
Rikard Falkeborn (1):
kunit: kunit_config: Fix parsing of CONFIG options with space
Uriel Guajardo (1):
kunit: show error if kunit results are not present
Documentation/dev-tools/kunit/faq.rst | 40
+++++++++++++++++++++
tools/testing/kunit/kunit.py | 4 ++-
tools/testing/kunit/kunit_config.py | 2 +-
tools/testing/kunit/kunit_parser.py | 8 ++---
tools/testing/kunit/kunit_tool_test.py | 11 ++++++
.../kunit/test_data/test_insufficient_memory.log | Bin
6 files changed, 59 insertions(+), 6 deletions(-)
create mode 100644
tools/testing/kunit/test_data/test_insufficient_memory.log
----------------------------------------------------------------
The test_vmlinux test uses hrtimer_nanosleep as hook to test tracing
programs. But in a kernel built by clang, which performs more aggresive
inlining, that function gets inlined into its caller SyS_nanosleep.
Therefore, even though fentry and kprobe do hook on the function,
they aren't triggered by the call to nanosleep in the test.
A possible fix is switching to use a function that is less likely to
be inlined, such as hrtimer_range_start_ns. The EXPORT_SYMBOL functions
shouldn't be inlined based on the description of [1], therefore safe
to use for this test. Also the arguments of this function include the
duration of sleep, therefore suitable for test verification.
[1] af3b56289be1 time: don't inline EXPORT_SYMBOL functions
Tested:
In a clang build kernel, before this change, the test fails:
test_vmlinux:PASS:skel_open 0 nsec
test_vmlinux:PASS:skel_attach 0 nsec
test_vmlinux:PASS:tp 0 nsec
test_vmlinux:PASS:raw_tp 0 nsec
test_vmlinux:PASS:tp_btf 0 nsec
test_vmlinux:FAIL:kprobe not called
test_vmlinux:FAIL:fentry not called
After switching to hrtimer_range_start_ns, the test passes:
test_vmlinux:PASS:skel_open 0 nsec
test_vmlinux:PASS:skel_attach 0 nsec
test_vmlinux:PASS:tp 0 nsec
test_vmlinux:PASS:raw_tp 0 nsec
test_vmlinux:PASS:tp_btf 0 nsec
test_vmlinux:PASS:kprobe 0 nsec
test_vmlinux:PASS:fentry 0 nsec
Signed-off-by: Hao Luo <haoluo(a)google.com>
Acked-by: Andrii Nakryiko <andriin(a)fb.com>
---
Changelog since v1:
- More accurate commit messages
tools/testing/selftests/bpf/progs/test_vmlinux.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/bpf/progs/test_vmlinux.c b/tools/testing/selftests/bpf/progs/test_vmlinux.c
index 5611b564d3b1..29fa09d6a6c6 100644
--- a/tools/testing/selftests/bpf/progs/test_vmlinux.c
+++ b/tools/testing/selftests/bpf/progs/test_vmlinux.c
@@ -63,20 +63,20 @@ int BPF_PROG(handle__tp_btf, struct pt_regs *regs, long id)
return 0;
}
-SEC("kprobe/hrtimer_nanosleep")
-int BPF_KPROBE(handle__kprobe,
- ktime_t rqtp, enum hrtimer_mode mode, clockid_t clockid)
+SEC("kprobe/hrtimer_start_range_ns")
+int BPF_KPROBE(handle__kprobe, struct hrtimer *timer, ktime_t tim, u64 delta_ns,
+ const enum hrtimer_mode mode)
{
- if (rqtp == MY_TV_NSEC)
+ if (tim == MY_TV_NSEC)
kprobe_called = true;
return 0;
}
-SEC("fentry/hrtimer_nanosleep")
-int BPF_PROG(handle__fentry,
- ktime_t rqtp, enum hrtimer_mode mode, clockid_t clockid)
+SEC("fentry/hrtimer_start_range_ns")
+int BPF_PROG(handle__fentry, struct hrtimer *timer, ktime_t tim, u64 delta_ns,
+ const enum hrtimer_mode mode)
{
- if (rqtp == MY_TV_NSEC)
+ if (tim == MY_TV_NSEC)
fentry_called = true;
return 0;
}
--
2.27.0.212.ge8ba1cc988-goog
Commit 8b59cd81dc5e ("kbuild: ensure full rebuild when the compiler is
updated") introduced a new CONFIG option CONFIG_CC_VERSION_TEXT. On my
system, this is set to "gcc (GCC) 10.1.0" which breaks KUnit config
parsing which did not like the spaces in the string.
Fix this by updating the regex to allow strings containing spaces.
Fixes: 8b59cd81dc5e ("kbuild: ensure full rebuild when the compiler is updated")
Signed-off-by: Rikard Falkeborn <rikard.falkeborn(a)gmail.com>
---
Maybe it would have been sufficient to just use
CONFIG_PATTERN = r'^CONFIG_(\w+)=(.*)$' instead?
tools/testing/kunit/kunit_config.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/kunit/kunit_config.py b/tools/testing/kunit/kunit_config.py
index e75063d603b5..02ffc3a3e5dc 100644
--- a/tools/testing/kunit/kunit_config.py
+++ b/tools/testing/kunit/kunit_config.py
@@ -10,7 +10,7 @@ import collections
import re
CONFIG_IS_NOT_SET_PATTERN = r'^# CONFIG_(\w+) is not set$'
-CONFIG_PATTERN = r'^CONFIG_(\w+)=(\S+)$'
+CONFIG_PATTERN = r'^CONFIG_(\w+)=(\S+|".*")$'
KconfigEntryBase = collections.namedtuple('KconfigEntry', ['name', 'value'])
--
2.27.0
The test_vmlinux test uses hrtimer_nanosleep as hook to test tracing
programs. But it seems Clang may have done an aggressive optimization,
causing fentry and kprobe to not hook on this function properly on a
Clang build kernel.
A possible fix is switching to use a more reliable function, e.g. the
ones exported to kernel modules such as hrtimer_range_start_ns. After
we switch to using hrtimer_range_start_ns, the test passes again even
on a clang build kernel.
Tested:
In a clang build kernel, the test fail even when the flags
{fentry, kprobe}_called are set unconditionally in handle__kprobe()
and handle__fentry(), which implies the programs do not hook on
hrtimer_nanosleep() properly. This could be because clang's code
transformation is too aggressive.
test_vmlinux:PASS:skel_open 0 nsec
test_vmlinux:PASS:skel_attach 0 nsec
test_vmlinux:PASS:tp 0 nsec
test_vmlinux:PASS:raw_tp 0 nsec
test_vmlinux:PASS:tp_btf 0 nsec
test_vmlinux:FAIL:kprobe not called
test_vmlinux:FAIL:fentry not called
After we switch to hrtimer_range_start_ns, the test passes.
test_vmlinux:PASS:skel_open 0 nsec
test_vmlinux:PASS:skel_attach 0 nsec
test_vmlinux:PASS:tp 0 nsec
test_vmlinux:PASS:raw_tp 0 nsec
test_vmlinux:PASS:tp_btf 0 nsec
test_vmlinux:PASS:kprobe 0 nsec
test_vmlinux:PASS:fentry 0 nsec
Signed-off-by: Hao Luo <haoluo(a)google.com>
---
tools/testing/selftests/bpf/progs/test_vmlinux.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/bpf/progs/test_vmlinux.c b/tools/testing/selftests/bpf/progs/test_vmlinux.c
index 5611b564d3b1..29fa09d6a6c6 100644
--- a/tools/testing/selftests/bpf/progs/test_vmlinux.c
+++ b/tools/testing/selftests/bpf/progs/test_vmlinux.c
@@ -63,20 +63,20 @@ int BPF_PROG(handle__tp_btf, struct pt_regs *regs, long id)
return 0;
}
-SEC("kprobe/hrtimer_nanosleep")
-int BPF_KPROBE(handle__kprobe,
- ktime_t rqtp, enum hrtimer_mode mode, clockid_t clockid)
+SEC("kprobe/hrtimer_start_range_ns")
+int BPF_KPROBE(handle__kprobe, struct hrtimer *timer, ktime_t tim, u64 delta_ns,
+ const enum hrtimer_mode mode)
{
- if (rqtp == MY_TV_NSEC)
+ if (tim == MY_TV_NSEC)
kprobe_called = true;
return 0;
}
-SEC("fentry/hrtimer_nanosleep")
-int BPF_PROG(handle__fentry,
- ktime_t rqtp, enum hrtimer_mode mode, clockid_t clockid)
+SEC("fentry/hrtimer_start_range_ns")
+int BPF_PROG(handle__fentry, struct hrtimer *timer, ktime_t tim, u64 delta_ns,
+ const enum hrtimer_mode mode)
{
- if (rqtp == MY_TV_NSEC)
+ if (tim == MY_TV_NSEC)
fentry_called = true;
return 0;
}
--
2.27.0.212.ge8ba1cc988-goog
The goal for this series is to introduce the hmm_range_fault() output
array flags HMM_PFN_PMD and HMM_PFN_PUD. This allows a device driver to
know that a given 4K PFN is actually mapped by the CPU using either a
PMD sized or PUD sized CPU page table entry and therefore the device
driver can safely map system memory using larger device MMU PTEs.
The series is based on 5.8.0-rc3 and is intended for Jason Gunthorpe's
hmm tree. These were originally part of a larger series:
https://lore.kernel.org/linux-mm/20200619215649.32297-1-rcampbell@nvidia.co…
Changes in v2:
Make the hmm_range_fault() API changes into a separate series and add
two output flags for PMD/PUD instead of a single compund page flag as
suggested by Jason Gunthorpe.
Make the nouveau page table changes a separate patch as suggested by
Ben Skeggs.
Only add support for 2MB nouveau mappings initially since changing the
1:1 CPU/GPU page table size assumptions requires a bigger set of changes.
Rebase to 5.8.0-rc3.
Ralph Campbell (5):
nouveau/hmm: fault one page at a time
mm/hmm: add output flags for PMD/PUD page mapping
nouveau: fix mapping 2MB sysmem pages
nouveau/hmm: support mapping large sysmem pages
hmm: add tests for HMM_PFN_PMD flag
drivers/gpu/drm/nouveau/nouveau_svm.c | 238 ++++++++----------
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 5 +-
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 82 ++++++
include/linux/hmm.h | 11 +-
lib/test_hmm.c | 4 +
lib/test_hmm_uapi.h | 4 +
mm/hmm.c | 13 +-
tools/testing/selftests/vm/hmm-tests.c | 76 ++++++
8 files changed, 290 insertions(+), 143 deletions(-)
--
2.20.1
## TL;DR
This patchset adds a centralized executor to dispatch tests rather than
relying on late_initcall to schedule each test suite separately along
with a couple of new features that depend on it.
Also, sorry for the extreme delay in getting this out. Part of the delay
came from finding that there were actually several architectures that
the previous revision of this patchset didn't work on, so I went through
and attempted to test this patchset on every architecture - more on that
later.
## What am I trying to do?
Conceptually, I am trying to provide a mechanism by which test suites
can be grouped together so that they can be reasoned about collectively.
The last two of three patches in this series add features which depend
on this:
PATCH 8/11 Prints out a test plan[1] right before KUnit tests are run;
this is valuable because it makes it possible for a test
harness to detect whether the number of tests run matches the
number of tests expected to be run, ensuring that no tests
silently failed. The test plan includes a count of tests that
will run. With the centralized executor, the tests are
located in a single data structure and thus can be counted.
PATCH 9/11 Add a new kernel command-line option which allows the user to
specify that the kernel poweroff, halt, or reboot after
completing all KUnit tests; this is very handy for running
KUnit tests on UML or a VM so that the UML/VM process exits
cleanly immediately after running all tests without needing a
special initramfs. The centralized executor provides a
definitive point when all tests have completed and the
poweroff, halt, or reboot could occur.
In addition, by dispatching tests from a single location, we can
guarantee that all KUnit tests run after late_init is complete, which
was a concern during the initial KUnit patchset review (this has not
been a problem in practice, but resolving with certainty is nevertheless
desirable).
Other use cases for this exist, but the above features should provide an
idea of the value that this could provide.
## Changes since last revision:
- On the last revision I got some messages from 0day that showed that
this patchset didn't work on several architectures, one issue that
this patchset addresses is that we were aligning both memory segments
as well as structures in the segments to specific byte boundaries
which was incorrect.
- The issue mentioned above also caused me to test on additional
architectures which revealed that some architectures other than UML
do not use the default init linker section macro that most
architectures use. There are now several new patches (2, 3, 4, and
6).
- Fixed a formatting consistency issue in the kernel params
documentation patch (9/9).
- Add a brief blurb on how and when the kunit_test_suite macro works.
## Remaining work to be done:
The only architecture for which I was able to get a compiler, but was
apparently unable to get KUnit into a section that the executor to see
was m68k - not sure why.
Alan Maguire (1):
kunit: test: create a single centralized executor for all tests
Brendan Higgins (10):
vmlinux.lds.h: add linker section for KUnit test suites
arch: arm64: add linker section for KUnit test suites
arch: microblaze: add linker section for KUnit test suites
arch: powerpc: add linker section for KUnit test suites
arch: um: add linker section for KUnit test suites
arch: xtensa: add linker section for KUnit test suites
init: main: add KUnit to kernel init
kunit: test: add test plan to KUnit TAP format
Documentation: Add kunit_shutdown to kernel-parameters.txt
Documentation: kunit: add a brief blurb about kunit_test_suite
.../admin-guide/kernel-parameters.txt | 8 ++
Documentation/dev-tools/kunit/usage.rst | 5 ++
arch/arm64/kernel/vmlinux.lds.S | 3 +
arch/microblaze/kernel/vmlinux.lds.S | 4 +
arch/powerpc/kernel/vmlinux.lds.S | 4 +
arch/um/include/asm/common.lds.S | 4 +
arch/xtensa/kernel/vmlinux.lds.S | 4 +
include/asm-generic/vmlinux.lds.h | 8 ++
include/kunit/test.h | 73 ++++++++++++-----
init/main.c | 4 +
lib/kunit/Makefile | 3 +-
lib/kunit/executor.c | 63 +++++++++++++++
lib/kunit/test.c | 13 +--
tools/testing/kunit/kunit_kernel.py | 2 +-
tools/testing/kunit/kunit_parser.py | 74 +++++++++++++++---
.../test_is_test_passed-all_passed.log | Bin 1562 -> 1567 bytes
.../test_data/test_is_test_passed-crash.log | Bin 3016 -> 3021 bytes
.../test_data/test_is_test_passed-failure.log | Bin 1700 -> 1705 bytes
18 files changed, 226 insertions(+), 46 deletions(-)
create mode 100644 lib/kunit/executor.c
base-commit: 4333a9b0b67bb4e8bcd91bdd80da80b0ec151162
prerequisite-patch-id: 2d4b5aa9fa8ada9ae04c8584b47c299a822b9455
prerequisite-patch-id: 582b6d9d28ce4b71628890ec832df6522ca68de0
These patches are available for download with dependencies here:
https://kunit-review.googlesource.com/c/linux/+/3829
[1] https://github.com/isaacs/testanything.github.io/blob/tap14/tap-version-14-…
[2] https://patchwork.kernel.org/patch/11383635/
--
2.27.0.212.ge8ba1cc988-goog
It is Very Rude to clear dmesg in test scripts. That's because the
script may be part of a larger test run, and clearing dmesg
potentially destroys the output of other tests.
We can avoid using dmesg -c by saving the content of dmesg before the
test, and then using diff to compare that to the dmesg afterward,
producing a log with just the added lines.
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
---
tools/testing/selftests/lkdtm/run.sh | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/lkdtm/run.sh b/tools/testing/selftests/lkdtm/run.sh
index dadf819148a4..0b409e187c7b 100755
--- a/tools/testing/selftests/lkdtm/run.sh
+++ b/tools/testing/selftests/lkdtm/run.sh
@@ -59,23 +59,25 @@ if [ -z "$expect" ]; then
expect="call trace:"
fi
-# Clear out dmesg for output reporting
-dmesg -c >/dev/null
-
# Prepare log for report checking
-LOG=$(mktemp --tmpdir -t lkdtm-XXXXXX)
+LOG=$(mktemp --tmpdir -t lkdtm-log-XXXXXX)
+DMESG=$(mktemp --tmpdir -t lkdtm-dmesg-XXXXXX)
cleanup() {
- rm -f "$LOG"
+ rm -f "$LOG" "$DMESG"
}
trap cleanup EXIT
+# Save existing dmesg so we can detect new content below
+dmesg > "$DMESG"
+
# Most shells yell about signals and we're expecting the "cat" process
# to usually be killed by the kernel. So we have to run it in a sub-shell
# and silence errors.
($SHELL -c 'cat <(echo '"$test"') >'"$TRIGGER" 2>/dev/null) || true
# Record and dump the results
-dmesg -c >"$LOG"
+dmesg | diff --changed-group-format='%>' --unchanged-group-format='' "$DMESG" - > "$LOG" || true
+
cat "$LOG"
# Check for expected output
if egrep -qi "$expect" "$LOG" ; then
base-commit: 192ffb7515839b1cc8457e0a8c1e09783de019d3
--
2.25.1
Hi Greg,
(Since this was aleady pending, I just spun a v2, resent here.)
Can you please apply these patches to your drivers/misc tree for LKDTM?
It's mostly a collection of fixes and improvements and tweaks to the
selftest integration.
Thanks!
-Kees
v2: - add fix for UML build failures (Randy, Richard)
v1: https://lore.kernel.org/lkml/20200529200347.2464284-1-keescook@chromium.org/
Kees Cook (4):
lkdtm: Avoid more compiler optimizations for bad writes
lkdtm/heap: Avoid edge and middle of slabs
selftests/lkdtm: Reset WARN_ONCE to avoid false negatives
lkdtm: Make arch-specific tests always available
drivers/misc/lkdtm/bugs.c | 49 +++++++++++++------------
drivers/misc/lkdtm/heap.c | 9 +++--
drivers/misc/lkdtm/lkdtm.h | 2 -
drivers/misc/lkdtm/perms.c | 22 +++++++----
drivers/misc/lkdtm/usercopy.c | 7 +++-
tools/testing/selftests/lkdtm/run.sh | 6 +++
tools/testing/selftests/lkdtm/tests.txt | 1 +
7 files changed, 58 insertions(+), 38 deletions(-)
--
2.25.1
Hi Greg,
Can you please apply these patches to your drivers/misc tree for LKDTM?
It's mostly a collection of fixes and improvements and tweaks to the
selftest integration.
Thanks!
-Kees
Kees Cook (4):
lkdtm: Avoid more compiler optimizations for bad writes
lkdtm/heap: Avoid edge and middle of slabs
selftests/lkdtm: Reset WARN_ONCE to avoid false negatives
lkdtm: Make arch-specific tests always available
drivers/misc/lkdtm/bugs.c | 45 +++++++++++++------------
drivers/misc/lkdtm/heap.c | 9 ++---
drivers/misc/lkdtm/lkdtm.h | 2 --
drivers/misc/lkdtm/perms.c | 22 ++++++++----
drivers/misc/lkdtm/usercopy.c | 7 ++--
tools/testing/selftests/lkdtm/run.sh | 6 ++++
tools/testing/selftests/lkdtm/tests.txt | 1 +
7 files changed, 56 insertions(+), 36 deletions(-)
--
2.25.1
## TL;DR
This patchset adds a centralized executor to dispatch tests rather than
relying on late_initcall to schedule each test suite separately along
with a couple of new features that depend on it.
Also, sorry for the delay in getting this new revision out. I have been
really busy for the past couple weeks.
## What am I trying to do?
Conceptually, I am trying to provide a mechanism by which test suites
can be grouped together so that they can be reasoned about collectively.
The last two of three patches in this series add features which depend
on this:
PATCH 5/7 Prints out a test plan[1] right before KUnit tests are run;
this is valuable because it makes it possible for a test
harness to detect whether the number of tests run matches the
number of tests expected to be run, ensuring that no tests
silently failed. The test plan includes a count of tests that
will run. With the centralized executor, the tests are located
in a single data structure and thus can be counted.
PATCH 6/7 Add a new kernel command-line option which allows the user to
specify that the kernel poweroff, halt, or reboot after
completing all KUnit tests; this is very handy for running
KUnit tests on UML or a VM so that the UML/VM process exits
cleanly immediately after running all tests without needing a
special initramfs. The centralized executor provides a
definitive point when all tests have completed and the
poweroff, halt, or reboot could occur.
In addition, by dispatching tests from a single location, we can
guarantee that all KUnit tests run after late_init is complete, which
was a concern during the initial KUnit patchset review (this has not
been a problem in practice, but resolving with certainty is nevertheless
desirable).
Other use cases for this exist, but the above features should provide an
idea of the value that this could provide.
## Changes since last revision:
- On patch 7/7, I added some additional wording around the
kunit_shutdown command line option explaining that it runs after
built-in tests as suggested by Frank.
- On the coverletter, I improved some wording and added a missing link.
I also specified the base-commit for the series.
- Frank asked for some changes to the documentation; however, David is
taking care of that in a separate patch[2], so I did not make those
changes here. There will be some additional changes necessary
after David's patch is applied.
Alan Maguire (1):
kunit: test: create a single centralized executor for all tests
Brendan Higgins (5):
vmlinux.lds.h: add linker section for KUnit test suites
arch: um: add linker section for KUnit test suites
init: main: add KUnit to kernel init
kunit: test: add test plan to KUnit TAP format
Documentation: Add kunit_shutdown to kernel-parameters.txt
David Gow (1):
kunit: Add 'kunit_shutdown' option
.../admin-guide/kernel-parameters.txt | 8 ++
arch/um/include/asm/common.lds.S | 4 +
include/asm-generic/vmlinux.lds.h | 8 ++
include/kunit/test.h | 82 ++++++++++++-------
init/main.c | 4 +
lib/kunit/Makefile | 3 +-
lib/kunit/executor.c | 71 ++++++++++++++++
lib/kunit/test.c | 11 ---
tools/testing/kunit/kunit_kernel.py | 2 +-
tools/testing/kunit/kunit_parser.py | 76 ++++++++++++++---
.../test_is_test_passed-all_passed.log | 1 +
.../test_data/test_is_test_passed-crash.log | 1 +
.../test_data/test_is_test_passed-failure.log | 1 +
13 files changed, 218 insertions(+), 54 deletions(-)
create mode 100644 lib/kunit/executor.c
base-commit: a2f0b878c3ca531a1706cb2a8b079cea3b17bafc
[1] https://github.com/isaacs/testanything.github.io/blob/tap14/tap-version-14-…
[2] https://patchwork.kernel.org/patch/11383635/
--
2.25.1.481.gfbce0eb801-goog
The arm64 signal tests generate warnings during build since both they and
the toplevel lib.mk define a clean target:
Makefile:25: warning: overriding recipe for target 'clean'
../../lib.mk:126: warning: ignoring old recipe for target 'clean'
Since the inclusion of lib.mk is in the signal Makefile there is no
situation where this warning could be avoided so just remove the redundant
clean target.
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
tools/testing/selftests/arm64/signal/Makefile | 4 ----
1 file changed, 4 deletions(-)
diff --git a/tools/testing/selftests/arm64/signal/Makefile b/tools/testing/selftests/arm64/signal/Makefile
index b497cfea4643..ac4ad0005715 100644
--- a/tools/testing/selftests/arm64/signal/Makefile
+++ b/tools/testing/selftests/arm64/signal/Makefile
@@ -21,10 +21,6 @@ include ../../lib.mk
$(TEST_GEN_PROGS): $(PROGS)
cp $(PROGS) $(OUTPUT)/
-clean:
- $(CLEAN)
- rm -f $(PROGS)
-
# Common test-unit targets to build common-layout test-cases executables
# Needs secondary expansion to properly include the testcase c-file in pre-reqs
.SECONDEXPANSION:
--
2.20.1
Tim Bird started a thread [1] proposing that he document the selftest result
format used by Linux kernel tests.
[1] https://lore.kernel.org/r/CY4PR13MB1175B804E31E502221BC8163FD830@CY4PR13MB1…
The issue of messages generated by the kernel being tested (that are not
messages directly created by the tests, but are instead triggered as a
side effect of the test) came up. In this thread, I will call these
messages "expected messages". Instead of sidetracking that thread with
a proposal to handle expected messages, I am starting this new thread.
I implemented an API for expected messages that are triggered by tests
in the Devicetree unittest code, with the expectation that the specific
details may change when the Devicetree unittest code adapts the KUnit
API. It seems appropriate to incorporate the concept of expected
messages in Tim's documentation instead of waiting to address the
subject when the Devicetree unittest code adapts the KUnit API, since
Tim's document may become the kernel selftest standard.
Instead of creating a very long email containing multiple objects,
I will reply to this email with a separate reply for each of:
The "expected messages" API implemention and use can be from
drivers/of/unittest.c in the mainline kernel.
of_unittest_expect - A proof of concept perl program to filter console
output containing expected messages output
of_unittest_expect is also available by cloning
https://github.com/frowand/dt_tools.git
An example raw console output with timestamps and expect messages.
An example of console output processed by filter program
of_unittest_expect to be more human readable. The expected
messages are not removed, but are flagged.
An example of console output processed by filter program
of_unittest_expect to be more human readable. The expected
messages are removed instead of being flagged.
Fix
make[1]: execvp: /bin/sh: Argument list too long
encountered with some shells and a couple of more potential problems
in that part of code.
Yauheni Kaliuta (3):
selftests: do not use .ONESHELL
selftests: fix condition in run_tests
selftests: simplify run_tests
tools/testing/selftests/lib.mk | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
--
2.26.2
Changeset 1eecbcdca2bd ("docs: move protection-keys.rst to the core-api book")
from Jun 7, 2019 converted protection-keys.txt file to ReST.
A recent change at protection_keys.c partially reverted such
changeset, causing it to point to a non-existing file:
- * Tests x86 Memory Protection Keys (see Documentation/core-api/protection-keys.rst)
+ * Tests Memory Protection Keys (see Documentation/vm/protection-keys.txt)
It sounds to me that the changeset that introduced such change
4645e3563673 ("selftests/vm/pkeys: rename all references to pkru to a generic name")
could also have other side effects, as it sounds that it was not
generated against uptream code, but, instead, against a version
older than Jun 7, 2019.
Fixes: 4645e3563673 ("selftests/vm/pkeys: rename all references to pkru to a generic name")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org>
---
tools/testing/selftests/vm/protection_keys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/vm/protection_keys.c b/tools/testing/selftests/vm/protection_keys.c
index fc19addcb5c8..fdbb602ecf32 100644
--- a/tools/testing/selftests/vm/protection_keys.c
+++ b/tools/testing/selftests/vm/protection_keys.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Tests Memory Protection Keys (see Documentation/vm/protection-keys.txt)
+ * Tests Memory Protection Keys (see Documentation/core-api/protection-keys.rst)
*
* There are examples in here of:
* * how to set protection keys on memory
--
2.26.2
Some months ago I started work on a document to formalize how
kselftest implements the TAP specification. However, I didn't finish
that work. Maybe it's time to do so now.
kselftest has developed a few differences from the original
TAP specification, and some extensions that I believe are worth
documenting.
Essentially, we have created our own KTAP (kernel TAP)
format. I think it is worth documenting our conventions, in order to
keep everyone on the same page.
Below is a partially completed document on my understanding
of KTAP, based on examination of some of the kselftest test
output. I have not reconciled this with the kunit output format,
which I believe has some differences (which maybe we should
resolve before we get too far into this).
I submit the document now, before it is finished, because a patch
was recently introduced to alter one of the result conventions
(from SKIP='not ok' to SKIP='ok').
See the document include inline below
====== start of ktap-doc-rfc.txt ======
Selftest preferred output format
--------------------------------
The linux kernel selftest system uses TAP (Test Anything Protocol)
output to make testing results consumable by automated systems. A
number of Continuous Integration (CI) systems test the kernel every
day. It is useful for these systems that output from selftest
programs be consistent and machine-parsable.
At the same time, it is useful for test results to be human-readable
as well.
The kernel test result format is based on a variation TAP
TAP is a simple text-based format that is
documented on the TAP home page (http://testanything.org/). There
is an official TAP13 specification here:
http://testanything.org/tap-version-13-specification.html
The kernel test result format consists of 5 major elements,
4 of which are line-based:
* the output version line
* the plan line
* one or more test result lines (also called test result lines)
* a possible "Bail out!" line
optional elements:
* diagnostic data
The 5th element is diagnostic information, which is used to describe
items running in the test, and possibly to explain test results.
A sample test result is show below:
Some other lines may be placed the test harness, and are not emitted
by individual test programs:
* one or more test identification lines
* a possible results summary line
Here is an example:
TAP version 13
1..1
# selftests: cpufreq: main.sh
# pid 8101's current affinity mask: fff
# pid 8101's new affinity mask: 1
ok 1 selftests: cpufreq: main.sh
The output version line is: "TAP version 13"
The test plan is "1..1".
Element details
===============
Output version line
-------------------
The output version line is always "TAP version 13".
Although the kernel test result format has some additions
to the TAP13 format, the version line reported by kselftest tests
is (currently) always the exact string "TAP version 13"
This is always the first line of test output.
Test plan line
--------------
The test plan indicates the number of individual test cases intended to
be executed by the test. It always starts with "1.." and is followed
by the number of tests cases. In the example above, 1..1", indicates
that this test reports only 1 test case.
The test plan line can be placed in two locations:
* the second line of test output, when the number of test cases is known
in advance
* as the last line of test output, when the number of test cases is not
known in advance.
Most often, the number of test cases is known in advance, and the test plan
line appears as the second line of test output, immediately following
the output version line. The number of test cases might not be known
in advance if the number of tests is calculated from runtime data.
In this case, the test plan line is emitted as the last line of test
output.
Test result lines
-----------------
The test output consists of one or more test result lines that indicate
the actual results for the test. These have the format:
<result> <number> <description> [<directive>] [<diagnostic data>]
The ''result'' must appear at the start of a line (except for when a
test is nested, see below), and must consist of one of the following
two phrases:
* ok
* not ok
If the test passed, then the result is reported as "ok". If the test
failed, then the result is reported as "not ok". These must be in
lower case, exactly as shown.
The ''number'' in the test result line represents the number of the
test case being performed by the test program. This is often used by
test harnesses as a unique identifier for each test case. The test
number is a base-10 number, starting with 1. It should increase by
one for each new test result line emitted. If possible the number
for a test case should be kept the same over the lifetime of the test.
The ''description'' is a short description of the test case.
This can be any string of words, but should avoid using colons (':')
except as part of a fully qualifed test case name (see below).
Finally, it is possible to use a test directive to indicate another
possible outcome for a test: that it was skipped. To report that
a test case was skipped, the result line should start with the
result "not ok", and the directive "# SKIP" should be placed after
the test description. (Note that this deviates from the TAP13
specification).
A test may be skipped for a variety of reasons, ranging for
insufficient privileges to missing features or resources required
to execute that test case.
It is usually helpful if a diagnostic message is emitted to explain
the reasons for the skip. If the message is a single line and is
short, the diagnostic message may be placed after the '# SKIP'
directive on the same line as the test result. However, if it is
not on the test result line, it should precede the test line (see
diagnostic data, next).
Diagnostic data
---------------
Diagnostic data is text that reports on test conditions or test
operations, or that explains test results. In the kernel test
result format, diagnostic data is placed on lines that start with a
hash sign, followed by a space ('# ').
One special format of diagnostic data is a test identification line,
that has the fully qualified name of a test case. Such a test
identification line marks the start of test output for a test case.
In the example above, there are three lines that start with '#'
which precede the test result line:
# selftests: cpufreq: main.sh
# pid 8101's current affinity mask: fff
# pid 8101's new affinity mask: 1
These are used to indicate diagnostic data for the test case
'selftests: cpufreq: main.sh'
Material in comments between the identification line and the test
result line are diagnostic data that can help to interpret the
results of the test.
The TAP specification indicates that automated test harnesses may
ignore any line that is not one of the mandatory prescribed lines
(that is, the output format version line, the plan line, a test
result line, or a "Bail out!" line.)
Bail out!
---------
If a line in the test output starts with 'Bail out!', it indicates
that the test was aborted for some reason. It indicates that
the test is unable to proceed, and no additional tests will be
performed.
This can be used at the very beginning of a test, or anywhere in the
middle of the test, to indicate that the test can not continue.
--- from here on is not-yet-organized material
Tip:
- don't change the test plan based on skipped tests.
- it is better to report that a test case was skipped, than to
not report it
- that is, don't adjust the number of test cases based on skipped
tests
Other things to mention:
TAP13 elements not used:
- yaml for diagnostic messages
- reason: try to keep things line-based, since output from other things
may be interspersed with messages from the test itself
- TODO directive
KTAP Extensions beyond TAP13:
- nesting
- via indentation
- indentation makes it easier for humans to read
- test identifier
- multiple parts, separated by ':'
- summary lines
- can be skipped by CI systems that do their own calculations
Other notes:
- automatic assignment of result status based on exit code
Tips:
- do NOT describe the result in the test line
- the test case description should be the same whether the test
succeeds or fails
- use diagnostic lines to describe or explain results, if this is
desirable
- test numbers are considered harmful
- test harnesses should use the test description as the identifier
- test numbers change when testcases are added or removed
- which means that results can't be compared between different
versions of the test
- recommendations for diagnostic messages:
- reason for failure
- reason for skip
- diagnostic data should always preceding the result line
- problem: harness may emit result before test can do assessment
to determine reason for result
- this is what the kernel uses
Differences between kernel test result format and TAP13:
- in KTAP the "# SKIP" directive is placed after the description on
the test result line
====== start of ktap-doc-rfc.txt ======
OK - that's the end of the RFC doc.
Here are a few questions:
- is this document desired or not?
- is it too long or too short?
- if the document is desired, where should it be placed?
I assume somewhere under Documentation, and put into
.rst format. Suggestions for a name and location are welcome.
- is this document accurate?
I think KUNIT does a few things differently than this description.
- is the intent to have kunit and kselftest have the same output format?
if so, then these should be rationalized.
Finally,
- Should a SKIP result be 'ok' (TAP13 spec) or 'not ok' (current kselftest practice)?
See https://testanything.org/tap-version-13-specification.html
Regards,
-- Tim
These patches apply to linux-5.8.0-rc1. Patches 1-3 should probably go
into 5.8, the others can be queued for 5.9. Patches 4-6 improve the HMM
self tests. Patch 7-8 prepare nouveau for the meat of this series which
adds support and testing for compound page mapping of system memory
(patches 9-11) and compound page migration to device private memory
(patches 12-16). Since these changes are split across mm core, nouveau,
and testing, I'm guessing Jason Gunthorpe's HMM tree would be appropriate.
Ralph Campbell (16):
mm: fix migrate_vma_setup() src_owner and normal pages
nouveau: fix migrate page regression
nouveau: fix mixed normal and device private page migration
mm/hmm: fix test timeout on slower machines
mm/hmm/test: remove redundant page table invalidate
mm/hmm: test mixed normal and device private migrations
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
mm/hmm: optimize migrate_vma_setup() for holes
mm: support THP migration to device private memory
mm/thp: add THP allocation helper
mm/hmm/test: add self tests for THP migration
nouveau: support THP migration to private memory
drivers/gpu/drm/nouveau/nouveau_dmem.c | 177 +++++---
drivers/gpu/drm/nouveau/nouveau_svm.c | 241 +++++------
drivers/gpu/drm/nouveau/nouveau_svm.h | 3 +-
.../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 | 10 +-
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 3 -
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 29 +-
include/linux/gfp.h | 10 +
include/linux/hmm.h | 4 +-
include/linux/migrate.h | 1 +
include/linux/mm.h | 1 +
lib/test_hmm.c | 359 ++++++++++++----
lib/test_hmm_uapi.h | 2 +
mm/hmm.c | 10 +-
mm/huge_memory.c | 46 ++-
mm/internal.h | 1 -
mm/memory.c | 10 +-
mm/memremap.c | 9 +-
mm/migrate.c | 236 +++++++++--
mm/page_alloc.c | 1 +
tools/testing/selftests/vm/hmm-tests.c | 388 +++++++++++++++++-
22 files changed, 1203 insertions(+), 346 deletions(-)
--
2.20.1
On 6/20/20 9:37 PM, akpm(a)linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2020-06-20-21-36 has been uploaded to
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my -mm patch queue. Uploaded at random hopefully
> more than once a week.
drivers/misc/lkdtm/bugs.c has build errors when building UML for i386
(allmodconfig or allyesconfig):
In file included from ../drivers/misc/lkdtm/bugs.c:17:0:
../arch/x86/um/asm/desc.h:7:0: warning: "LDT_empty" redefined
#define LDT_empty(info) (\
In file included from ../arch/um/include/asm/mmu.h:10:0,
from ../include/linux/mm_types.h:18,
from ../include/linux/sched/signal.h:13,
from ../drivers/misc/lkdtm/bugs.c:11:
../arch/x86/um/asm/mm_context.h:65:0: note: this is the location of the previous definition
#define LDT_empty(info) (_LDT_empty(info))
../drivers/misc/lkdtm/bugs.c: In function ‘lkdtm_DOUBLE_FAULT’:
../drivers/misc/lkdtm/bugs.c:428:9: error: variable ‘d’ has initializer but incomplete type
struct desc_struct d = {
^~~~~~~~~~~
../drivers/misc/lkdtm/bugs.c:429:4: error: ‘struct desc_struct’ has no member named ‘type’
.type = 3, /* expand-up, writable, accessed data */
^~~~
../drivers/misc/lkdtm/bugs.c:429:11: warning: excess elements in struct initializer
.type = 3, /* expand-up, writable, accessed data */
^
../drivers/misc/lkdtm/bugs.c:429:11: note: (near initialization for ‘d’)
../drivers/misc/lkdtm/bugs.c:430:4: error: ‘struct desc_struct’ has no member named ‘p’
.p = 1, /* present */
^
../drivers/misc/lkdtm/bugs.c:430:8: warning: excess elements in struct initializer
.p = 1, /* present */
^
../drivers/misc/lkdtm/bugs.c:430:8: note: (near initialization for ‘d’)
../drivers/misc/lkdtm/bugs.c:431:4: error: ‘struct desc_struct’ has no member named ‘d’
.d = 1, /* 32-bit */
^
../drivers/misc/lkdtm/bugs.c:431:8: warning: excess elements in struct initializer
.d = 1, /* 32-bit */
^
../drivers/misc/lkdtm/bugs.c:431:8: note: (near initialization for ‘d’)
../drivers/misc/lkdtm/bugs.c:432:4: error: ‘struct desc_struct’ has no member named ‘g’
.g = 0, /* limit in bytes */
^
../drivers/misc/lkdtm/bugs.c:432:8: warning: excess elements in struct initializer
.g = 0, /* limit in bytes */
^
../drivers/misc/lkdtm/bugs.c:432:8: note: (near initialization for ‘d’)
../drivers/misc/lkdtm/bugs.c:433:4: error: ‘struct desc_struct’ has no member named ‘s’
.s = 1, /* not system */
^
../drivers/misc/lkdtm/bugs.c:433:8: warning: excess elements in struct initializer
.s = 1, /* not system */
^
../drivers/misc/lkdtm/bugs.c:433:8: note: (near initialization for ‘d’)
../drivers/misc/lkdtm/bugs.c:428:21: error: storage size of ‘d’ isn’t known
struct desc_struct d = {
^
../drivers/misc/lkdtm/bugs.c:437:2: error: implicit declaration of function ‘write_gdt_entry’; did you mean ‘init_wait_entry’? [-Werror=implicit-function-declaration]
write_gdt_entry(get_cpu_gdt_rw(smp_processor_id()),
^~~~~~~~~~~~~~~
init_wait_entry
../drivers/misc/lkdtm/bugs.c:437:18: error: implicit declaration of function ‘get_cpu_gdt_rw’; did you mean ‘get_cpu_ptr’? [-Werror=implicit-function-declaration]
write_gdt_entry(get_cpu_gdt_rw(smp_processor_id()),
^~~~~~~~~~~~~~
get_cpu_ptr
../drivers/misc/lkdtm/bugs.c:438:27: error: ‘DESCTYPE_S’ undeclared (first use in this function)
GDT_ENTRY_TLS_MIN, &d, DESCTYPE_S);
^~~~~~~~~~
../drivers/misc/lkdtm/bugs.c:438:27: note: each undeclared identifier is reported only once for each function it appears in
../drivers/misc/lkdtm/bugs.c:428:21: warning: unused variable ‘d’ [-Wunused-variable]
struct desc_struct d = {
^
cc1: some warnings being treated as errors
--
~Randy
Reported-by: Randy Dunlap <rdunlap(a)infradead.org>
As discussed in [1], KUnit tests have hitherto not had a particularly
consistent naming scheme. This adds documentation outlining how tests
and test suites should be named, including how those names should be
used in Kconfig entries and filenames.
[1]:
https://lore.kernel.org/linux-kselftest/202006141005.BA19A9D3@keescook/t/#u
Signed-off-by: David Gow <davidgow(a)google.com>
---
This is a first draft of some naming guidelines for KUnit tests. Note
that I haven't edited it for spelling/grammar/style yet: I wanted to get
some feedback on the actual naming conventions first.
The issues which came most to the forefront while writing it were:
- Do we want to make subsystems a more explicit thing (make the KUnit
framework recognise them, make suites KTAP subtests of them, etc)
- I'm leaning towards no, mainly because it doesn't seem necessary,
and it makes the subsystem-with-only-one-suite case ugly.
- Do we want to support (or encourage) Kconfig options and/or modules at
the subsystem level rather than the suite level?
- This could be nice: it'd avoid the proliferation of a large number
of tiny config options and modules, and would encourage the test for
<module> to be <module>_kunit, without other stuff in-between.
- As test names are also function names, it may actually make sense to
decorate them with "test" or "kunit" or the like.
- If we're testing a function "foo", "test_foo" seems like as good a
name for the function as any. Sure, many cases may could have better
names like "foo_invalid_context" or something, but that won't make
sense for everything.
- Alternatively, do we split up the test name and the name of the
function implementing the test?
Thoughts?
Documentation/dev-tools/kunit/index.rst | 1 +
Documentation/dev-tools/kunit/style.rst | 139 ++++++++++++++++++++++++
2 files changed, 140 insertions(+)
create mode 100644 Documentation/dev-tools/kunit/style.rst
diff --git a/Documentation/dev-tools/kunit/index.rst b/Documentation/dev-tools/kunit/index.rst
index e93606ecfb01..117c88856fb3 100644
--- a/Documentation/dev-tools/kunit/index.rst
+++ b/Documentation/dev-tools/kunit/index.rst
@@ -11,6 +11,7 @@ KUnit - Unit Testing for the Linux Kernel
usage
kunit-tool
api/index
+ style
faq
What is KUnit?
diff --git a/Documentation/dev-tools/kunit/style.rst b/Documentation/dev-tools/kunit/style.rst
new file mode 100644
index 000000000000..9363b5607262
--- /dev/null
+++ b/Documentation/dev-tools/kunit/style.rst
@@ -0,0 +1,139 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================
+Test Style and Nomenclature
+===========================
+
+Subsystems, Suites, and Tests
+=============================
+
+In order to make tests as easy to find as possible, they're grouped into suites
+and subsystems. A test suite is a group of tests which test a related area of
+the kernel, and a subsystem is a set of test suites which test different parts
+of the same kernel subsystem or driver.
+
+Subsystems
+----------
+
+Every test suite must belong to a subsystem. A subsystem is a collection of one
+or more KUnit test suites which test the same driver or part of the kernel. A
+rule of thumb is that a test subsystem should match a single kernel module. If
+the code being tested can't be compiled as a module, in many cases the subsystem
+should correspond to a directory in the source tree or an entry in the
+MAINTAINERS file. If unsure, follow the conventions set by tests in similar
+areas.
+
+Test subsystems should be named after the code being tested, either after the
+module (wherever possible), or after the directory or files being tested. Test
+subsystems should be named to avoid ambiguity where necessary.
+
+If a test subsystem name has multiple components, they should be separated by
+underscores. Do not include "test" or "kunit" directly in the subsystem name
+unless you are actually testing other tests or the kunit framework itself.
+
+Example subsystems could be:
+
+* ``ext4``
+* ``apparmor``
+* ``kasan``
+
+.. note::
+ The KUnit API and tools do not explicitly know about subsystems. They're
+ simply a way of categorising test suites and naming modules which
+ provides a simple, consistent way for humans to find and run tests. This
+ may change in the future, though.
+
+Suites
+------
+
+KUnit tests are grouped into test suites, which cover a specific area of
+functionality being tested. Test suites can have shared initialisation and
+shutdown code which is run for all tests in the suite.
+Not all subsystems will need to be split into multiple test suites (e.g. simple drivers).
+
+Test suites are named after the subsystem they are part of. If a subsystem
+contains several suites, the specific area under test should be appended to the
+subsystem name, separated by an underscore.
+
+The full test suite name (including the subsystem name) should be specified as
+the ``.name`` member of the ``kunit_suite`` struct, and forms the base for the
+module name (see below).
+
+Example test suites could include:
+
+* ``ext4_inode``
+* ``kunit_try_catch``
+* ``apparmor_property_entry``
+* ``kasan``
+
+Tests
+-----
+
+Individual tests consist of a single function which tests a constrained
+codepath, property, or function. In the test output, individual tests' results
+will show up as subtests of the suite's results.
+
+Tests should be named after what they're testing. This is often the name of the
+function being tested, with a description of the input or codepath being tested.
+As tests are C functions, they should be named and written in accordance with
+the kernel coding style.
+
+.. note::
+ As tests are themselves functions, their names cannot conflict with
+ other C identifiers in the kernel. This may require some creative
+ naming. It's a good idea to make your test functions `static` to avoid
+ polluting the global namespace.
+
+Should it be necessary to refer to a test outside the context of its test suite,
+the *fully-qualified* name of a test should be the suite name followed by the
+test name, separated by a colon (i.e. ``suite:test``).
+
+Test Kconfig Entries
+====================
+
+Every test suite should be tied to a Kconfig entry.
+
+This Kconfig entry must:
+
+* be named ``CONFIG_<name>_KUNIT_TEST``: where <name> is the name of the test
+ suite.
+* be listed either alongside the config entries for the driver/subsystem being
+ tested, or be under [Kernel Hacking]→[Kernel Testing and Coverage]
+* depend on ``CONFIG_KUNIT``
+* be visible only if ``CONFIG_KUNIT_ALL_TESTS`` is not enabled.
+* have a default value of ``CONFIG_KUNIT_ALL_TESTS``.
+* have a brief description of KUnit in the help text
+* include "If unsure, say N" in the help text
+
+Unless there's a specific reason not to (e.g. the test is unable to be built as
+a module), Kconfig entries for tests should be tristate.
+
+An example Kconfig entry:
+
+.. code-block:: none
+
+ config FOO_KUNIT_TEST
+ tristate "KUnit test for foo" if !KUNIT_ALL_TESTS
+ depends on KUNIT
+ default KUNIT_ALL_TESTS
+ help
+ This builds unit tests for foo.
+
+ 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
+
+
+Test Filenames
+==============
+
+Where possible, test suites should be placed in a separate source file in the
+same directory as the code being tested.
+
+This file should be named ``<suite>_kunit.c``. It may make sense to strip
+excessive namespacing from the source filename (e.g., ``firmware_kunit.c`` instead of
+``<drivername>_firmware.c``), but please ensure the module name does contain the
+full suite name.
+
+
--
2.27.0.111.gc72c7da667-goog
The reverted commit illegitly uses tpm2-tools. External dependencies are
absolutely forbidden from these tests. There is also the problem that
clearing is not necessarily wanted behavior if the test/target computer is
not used only solely for testing.
Fixes: a9920d3bad40 ("tpm: selftest: cleanup after unseal with wrong auth/policy test")
Cc: Tadeusz Struk <tadeusz.struk(a)intel.com>
Cc: stable(a)vger.kernel.org
Cc: linux-integrity(a)vger.kernel.org
Cc: linux-kselftest(a)vger.kernel.org
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
---
tools/testing/selftests/tpm2/test_smoke.sh | 5 -----
1 file changed, 5 deletions(-)
diff --git a/tools/testing/selftests/tpm2/test_smoke.sh b/tools/testing/selftests/tpm2/test_smoke.sh
index 663062701d5a..79f8e9da5d21 100755
--- a/tools/testing/selftests/tpm2/test_smoke.sh
+++ b/tools/testing/selftests/tpm2/test_smoke.sh
@@ -8,8 +8,3 @@ ksft_skip=4
python -m unittest -v tpm2_tests.SmokeTest
python -m unittest -v tpm2_tests.AsyncTest
-
-CLEAR_CMD=$(which tpm2_clear)
-if [ -n $CLEAR_CMD ]; then
- tpm2_clear -T device
-fi
--
2.25.1
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 the 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
v1
l3mdev: add infrastructure for table to VRF mapping
- define l3mdev_lock as static, thanks to Jakub Kicinski;
- move lookup_by_table_id_t from l3mdev.c to l3mdev.h and update the
l3mdev_dev_table_lookup_{un}register functions accordingly, thanks to
David Ahern.
vrf: track associations between VRF devices and tables
- change shared_tables type from 'int' to 'u32', thanks to Stephen Hemminger
and David Ahern;
- update comments for share_tables.
vrf: add sysctl parameter for strict mode
- change type 'void __user *buffer' to 'void *buffer' in argument 3 of
vrf_shared_table_handler function, thanks to Jakub Kicinski.
[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 | 39 ++
net/l3mdev/l3mdev.c | 93 ++++
.../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
Hi Linus,
Please pull the Kunit update for Linux 5.8-rc12.
This Kunit update for Linux 5.8-rc2 consists of:
- Adds a generic kunit_resource API extending it to support
resources that are passed in to kunit in addition kunit
allocated resources. In addition, KUnit resources are now
refcounted to avoid passed in resources being released while
in use by kunit.
- Add support for named resources.
diff is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:
Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-kunit-5.8-rc2
for you to fetch changes up to 7bf200b3a4ac10b1b0376c70b8c66ed39eae7cdd:
kunit: add support for named resources (2020-06-15 09:31:23 -0600)
----------------------------------------------------------------
linux-kselftest-kunit-5.8-rc2
This Kunit update for Linux 5.8-rc2 consists of:
- Adds a generic kunit_resource API extending it to support
resources that are passed in to kunit in addition kunit
allocated resources. In addition, KUnit resources are now
refcounted to avoid passed in resources being released while
in use by 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(-)
----------------------------------------------------------------
Hi Petr,
Given the realization about kernel log timestamps and partial log
comparison with v2, I respun a final version dropping the dmesg --notime
patch, fixed any rebase conflicts, and added a comment per your
suggestion.
I copied all the ack and review tags from v2 since the patchset is
unchanged otherwise. Hopefully this v3 minimizes any maintainer
fiddling on your end.
I did iterate through the patches and verified that I could run each
multiple times without the dmesg comparison getting confused.
Thanks,
-- Joe
v3:
- when modifying the dmesg comparision to select only new messages in
patch 1, add a comment explaining the importance of timestamps to
accurately pick from where the log left off at start_test [pmladek]
- since Petr determined that the timestamps were in fact very important
to maintain for the dmesg / diff comparision, drop the patch which
added --notime to dmesg invocations [pmladek]
- update the comparision regex filter for 'livepatch:' now that it's
going to be prefixed by '[timestamp] ' and no longer at the start of
the buffer line. This part of the log comparison should now be
unmodified by the patchset.
Joe Lawrence (3):
selftests/livepatch: Don't clear dmesg when running tests
selftests/livepatch: refine dmesg 'taints' in dmesg comparison
selftests/livepatch: add test delimiter to dmesg
tools/testing/selftests/livepatch/README | 16 +++---
.../testing/selftests/livepatch/functions.sh | 37 ++++++++++++-
.../selftests/livepatch/test-callbacks.sh | 55 ++++---------------
.../selftests/livepatch/test-ftrace.sh | 4 +-
.../selftests/livepatch/test-livepatch.sh | 12 +---
.../selftests/livepatch/test-shadow-vars.sh | 4 +-
.../testing/selftests/livepatch/test-state.sh | 21 +++----
7 files changed, 68 insertions(+), 81 deletions(-)
--
2.21.3
Hello!
This is a bit of thread-merge between [1] and [2]. tl;dr: add a way for
a seccomp user_notif process manager to inject files into the managed
process in order to handle emulation of various fd-returning syscalls
across security boundaries. Containers folks and Chrome are in need
of the feature, and investigating this solution uncovered (and fixed)
implementation issues with existing file sending routines.
I intend to carry this in the seccomp tree, unless someone has objections.
:) Please review and test!
-Kees
[1] https://lore.kernel.org/lkml/20200603011044.7972-1-sargun@sargun.me/
[2] https://lore.kernel.org/lkml/20200610045214.1175600-1-keescook@chromium.org/
Kees Cook (9):
net/scm: Regularize compat handling of scm_detach_fds()
fs: Move __scm_install_fd() to __fd_install_received()
fs: Add fd_install_received() wrapper for __fd_install_received()
pidfd: Replace open-coded partial fd_install_received()
fs: Expand __fd_install_received() to accept fd
selftests/seccomp: Make kcmp() less required
selftests/seccomp: Rename user_trap_syscall() to user_notif_syscall()
seccomp: Switch addfd to Extensible Argument ioctl
seccomp: Fix ioctl number for SECCOMP_IOCTL_NOTIF_ID_VALID
Sargun Dhillon (2):
seccomp: Introduce addfd ioctl to seccomp user notifier
selftests/seccomp: Test SECCOMP_IOCTL_NOTIF_ADDFD
fs/file.c | 65 ++++
include/linux/file.h | 16 +
include/uapi/linux/seccomp.h | 25 +-
kernel/pid.c | 11 +-
kernel/seccomp.c | 181 ++++++++-
net/compat.c | 55 ++-
net/core/scm.c | 50 +--
tools/testing/selftests/seccomp/seccomp_bpf.c | 350 +++++++++++++++---
8 files changed, 618 insertions(+), 135 deletions(-)
--
2.25.1
Commit 8b59cd81dc5 ("kbuild: ensure full rebuild when the compiler
is updated") added the environment variable CC_VERSION_TEXT,
parse_from_string() doesn't expect a string in value field and this
causes the failure below:
[iha@bbking linux]$ tools/testing/kunit/kunit.py run --timeout=60
[00:20:12] Configuring KUnit Kernel ...
Generating .config ...
Traceback (most recent call last):
File "tools/testing/kunit/kunit.py", line 347, in <module>
main(sys.argv[1:])
File "tools/testing/kunit/kunit.py", line 257, in main
result = run_tests(linux, request)
File "tools/testing/kunit/kunit.py", line 134, in run_tests
config_result = config_tests(linux, config_request)
File "tools/testing/kunit/kunit.py", line 64, in config_tests
success = linux.build_reconfig(request.build_dir, request.make_options)
File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_kernel.py", line 161, in build_reconfig
return self.build_config(build_dir, make_options)
File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_kernel.py", line 145, in build_config
return self.validate_config(build_dir)
File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_kernel.py", line 124, in validate_config
validated_kconfig.read_from_file(kconfig_path)
File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_config.py", line 89, in read_from_file
self.parse_from_string(f.read())
File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_config.py", line 85, in parse_from_string
raise KconfigParseError('Failed to parse: ' + line)
kunit_config.KconfigParseError: Failed to parse: CONFIG_CC_VERSION_TEXT="gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)"
Signed-off-by: Vitor Massaru Iha <vitor(a)massaru.org>
---
v2:
- maintains CC_VERSION_TEXT in the .config file to ensure full rebuild
when the compiler is updated.
---
tools/testing/kunit/kunit_config.py | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/tools/testing/kunit/kunit_config.py b/tools/testing/kunit/kunit_config.py
index e75063d603b5..c407c7c6a2b0 100644
--- a/tools/testing/kunit/kunit_config.py
+++ b/tools/testing/kunit/kunit_config.py
@@ -81,6 +81,12 @@ class Kconfig(object):
if line[0] == '#':
continue
+
+ if 'CONFIG_CC_VERSION_TEXT' in line:
+ name, value = line.split('=')
+ entry = KconfigEntry(name, value)
+ self.add_entry(entry)
+ continue
else:
raise KconfigParseError('Failed to parse: ' + line)
base-commit: 7bf200b3a4ac10b1b0376c70b8c66ed39eae7cdd
--
2.26.2
When separating out different phases of running tests[1]
(build/exec/parse/etc), the format of the KunitResult tuple changed
(adding an elapsed_time variable). This is not populated during a build
failure, causing kunit.py to crash.
This fixes [1] to probably populate the result variable, causing a
failing build to be reported properly.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
Signed-off-by: David Gow <davidgow(a)google.com>
---
tools/testing/kunit/kunit.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py
index 787b6d4ad716..f9b769f3437d 100755
--- a/tools/testing/kunit/kunit.py
+++ b/tools/testing/kunit/kunit.py
@@ -82,7 +82,9 @@ def build_tests(linux: kunit_kernel.LinuxSourceTree,
request.make_options)
build_end = time.time()
if not success:
- return KunitResult(KunitStatus.BUILD_FAILURE, 'could not build kernel')
+ return KunitResult(KunitStatus.BUILD_FAILURE,
+ 'could not build kernel',
+ build_end - build_start)
if not success:
return KunitResult(KunitStatus.BUILD_FAILURE,
'could not build kernel',
--
2.27.0.290.gba653c62da-goog
This is a small collection of tweaks for the shellscript side of the
livepatch tests. If anyone else has a small cleanup (or even just a
suggestion for a low-hanging change) and would like to tack it onto the
set, let me know.
based-on: livepatching.git, for-5.9/selftests-cleanup
merge-thru: livepatching.git
v2:
- use consistent start_test messages from the original echoes [mbenes]
- move start_test invocations to just after their descriptions [mbenes]
- clean up $SAVED_DMSG on trap EXIT [pmladek]
- grep longer kernel taint line, avoid word-matching [mbenes, pmladek]
- add "===== TEST: $test =====" delimiter patch [pmladek]
Joe Lawrence (4):
selftests/livepatch: Don't clear dmesg when running tests
selftests/livepatch: use $(dmesg --notime) instead of manually
filtering
selftests/livepatch: refine dmesg 'taints' in dmesg comparison
selftests/livepatch: add test delimiter to dmesg
tools/testing/selftests/livepatch/README | 16 +++---
.../testing/selftests/livepatch/functions.sh | 32 ++++++++++-
.../selftests/livepatch/test-callbacks.sh | 55 ++++---------------
.../selftests/livepatch/test-ftrace.sh | 4 +-
.../selftests/livepatch/test-livepatch.sh | 12 +---
.../selftests/livepatch/test-shadow-vars.sh | 4 +-
.../testing/selftests/livepatch/test-state.sh | 21 +++----
7 files changed, 63 insertions(+), 81 deletions(-)
--
2.21.3
Hi, I tried to run kselftest but it stops with logs below.
----------------------------
# ./run_kselftest.sh
[ 126.214906] kselftest: Running tests in android
TAP version 13
# selftests: android: run.sh
1..1
# ./run.sh: line 3: ./ion_test.sh: not found
not ok 1 selftests: android: run.sh # exit=127
[ 126.351342] kselftest: Running tests in breakpoints
TAP version 13
# selftests: breakpoints: step_after_suspend_test
1..2
[ 126.464495] PM: suspend entry (s2idle)
[ 126.496441] Filesystems sync: 0.031 seconds
[ 126.499299] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 126.501161] OOM killer disabled.
[ 126.501293] Freezing remaining freezable tasks ... (elapsed 0.001
seconds) done.
[ 126.503018] printk: Suspending console(s) (use no_console_suspend to debug)
----------------------------
I used kernel 5.6.15 stable on qemu(x86_64) and used kselftest from same source.
I built kernel adding configurations below to be able to mount
kselftest directory on host.
----------------------------
CONFIG_NET_9P=y
CONFIG_BLK_MQ_VIRTIO=y
CONFIG_NET_9P_VIRTIO=y
CONFIG_VIRTIO=y
CONFIG_NET_9P_DEBUG=y
CONFIG_VIRTIO_PCI=y
CONFIG_FUSE_FS=y
CONFIG_VIRTIO_PCI_LEGACY=y
CONFIG_9P_FS=y
CONFIG_VIRTIO_FS=y
CONFIG_9P_FS_POSIX_ACL=y
CONFIG_CRYPTO_ENGINE=m
CONFIG_9P_FS_SECURITY=y
CONFIG_CRYPTO_DEV_VIRTIO=m
CONFIG_GDB_SCRIPTS=y
CONFIG_DEBUG_INFO=y
----------------------------
Then, I boot kernel with rootfs geterated by buildroot like this.
----------------------------
qemu-system-x86_64 -kernel arch/x86/boot/bzImage -boot c -m 2049M -hda
../buildroot/output/images/rootfs.ext4 -append \
"root=/dev/sda rw console=ttyS0,115200 acpi=off nokaslr" -serial
mon:stdio -display none \
-virtfs local,path=/home/arabishi/work/kselftest/kselftest,mount_tag=host0,security_model=passthrough,id=host0
----------------------------
What should I do ?
We need to pass the arguments provided to --kmake-arg to all make
invocations. In particular, the make invocations generating the configs
need to see the final make arguments, e.g. if config variables depend on
particular variables that are passed to make.
For example, when using '--kcsan --kmake-arg CC=clang-11', we would lose
CONFIG_KCSAN=y due to 'make oldconfig' not seeing that we want to use a
compiler that supports KCSAN.
Signed-off-by: Marco Elver <elver(a)google.com>
---
tools/testing/selftests/rcutorture/bin/configinit.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/rcutorture/bin/configinit.sh b/tools/testing/selftests/rcutorture/bin/configinit.sh
index 93e80a42249a..d6e5ce084b1c 100755
--- a/tools/testing/selftests/rcutorture/bin/configinit.sh
+++ b/tools/testing/selftests/rcutorture/bin/configinit.sh
@@ -32,11 +32,11 @@ if test -z "$TORTURE_TRUST_MAKE"
then
make clean > $resdir/Make.clean 2>&1
fi
-make $TORTURE_DEFCONFIG > $resdir/Make.defconfig.out 2>&1
+make $TORTURE_KMAKE_ARG $TORTURE_DEFCONFIG > $resdir/Make.defconfig.out 2>&1
mv .config .config.sav
sh $T/upd.sh < .config.sav > .config
cp .config .config.new
-yes '' | make oldconfig > $resdir/Make.oldconfig.out 2> $resdir/Make.oldconfig.err
+yes '' | make $TORTURE_KMAKE_ARG oldconfig > $resdir/Make.oldconfig.out 2> $resdir/Make.oldconfig.err
# verify new config matches specification.
configcheck.sh .config $c
--
2.27.0.290.gba653c62da-goog
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:
- correct compilation error when CONFIG_FW_LOADER not defined
Changes from v7:
- 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 request_partial_firmware_into_buf
test_firmware: add partial read support for request_firmware_into_buf
firmware: test partial file reads of request_partial_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
According to the TAP specification, a skipped test must be marked as "ok"
and annotated with the SKIP directive, for example
ok 23 # skip Insufficient flogiston pressure.
(https://testanything.org/tap-specification.html)
Fix the runner script to match this.
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
---
tools/testing/selftests/kselftest/runner.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kselftest/runner.sh b/tools/testing/selftests/kselftest/runner.sh
index 676b3a8b114d..f4815cbcd60f 100644
--- a/tools/testing/selftests/kselftest/runner.sh
+++ b/tools/testing/selftests/kselftest/runner.sh
@@ -77,7 +77,7 @@ run_one()
echo "ok $test_num $TEST_HDR_MSG") ||
(rc=$?; \
if [ $rc -eq $skip_rc ]; then \
- echo "not ok $test_num $TEST_HDR_MSG # SKIP"
+ echo "ok $test_num $TEST_HDR_MSG # SKIP"
elif [ $rc -eq $timeout_rc ]; then \
echo "#"
echo "not ok $test_num $TEST_HDR_MSG # TIMEOUT"
--
2.26.2
On Mon, Jun 15, 2020 at 03:41:54PM +0000, patchwork-bot+linux-kselftest(a)kernel.org wrote:
> Hello:
>
> This patch was applied to shuah/linux-kselftest.git (refs/heads/next).
Hi! Thanks for snagging this, however, see below...
>
> On Wed, 20 May 2020 02:05:56 -0700 you wrote:
> > While working on commit b5372fe5dc84 ("exec: load_script: Do not exec
> > truncated interpreter path"), I wrote a series of test scripts to verify
> > corner cases. However, soon after, commit 6eb3c3d0a52d ("exec: increase
> > BINPRM_BUF_SIZE to 256") landed, resulting in the tests needing to be
> > refactored for the larger BINPRM_BUF_SIZE, which got lost on my TODO
> > list. During the recent exec refactoring work[1], the need for these tests
> > resurfaced, so I've finished them up for addition to the kernel selftests.
> >
> > [...]
>
>
> Here is a summary with links:
> - selftests/exec: Add binfmt_script regression test
> https://git.kernel.org/shuah/linux-kselftest/c/b081320f0693cce0394f7c8bad9f…
>
> You are awesome, thank you!
This was already picked up by Eric for this execve series, and has
already landed in Linus's tree as b081320f0693cce0394f7c8bad9fba0b25982186
--
Kees Cook
This is a small collection of tweaks for the shellscript side of the
livepatch tests. If anyone else has a small cleanup (or even just a
suggestion for a low-hanging change) and would like to tack it onto the
set, let me know.
based-on: livepatching.git, for-5.9/selftests-cleanup
merge-thru: livepatching.git
Joe Lawrence (3):
selftests/livepatch: Don't clear dmesg when running tests
selftests/livepatch: use $(dmesg --notime) instead of manually
filtering
selftests/livepatch: filter 'taints' from dmesg comparison
tools/testing/selftests/livepatch/README | 16 +++---
.../testing/selftests/livepatch/functions.sh | 16 +++++-
.../selftests/livepatch/test-callbacks.sh | 55 ++++---------------
.../selftests/livepatch/test-ftrace.sh | 5 +-
.../selftests/livepatch/test-livepatch.sh | 15 +----
.../selftests/livepatch/test-shadow-vars.sh | 5 +-
.../testing/selftests/livepatch/test-state.sh | 20 ++-----
7 files changed, 43 insertions(+), 89 deletions(-)
--
2.21.3
Changeset 1eecbcdca2bd ("docs: move protection-keys.rst to the core-api book")
from Jun 7, 2019 converted protection-keys.txt file to ReST.
A recent change at protection_keys.c partially reverted such
changeset, causing it to point to a non-existing file:
- * Tests x86 Memory Protection Keys (see Documentation/core-api/protection-keys.rst)
+ * Tests Memory Protection Keys (see Documentation/vm/protection-keys.txt)
It sounds to me that the changeset that introduced such change
4645e3563673 ("selftests/vm/pkeys: rename all references to pkru to a generic name")
could also have other side effects, as it sounds that it was not
generated against uptream code, but, instead, against a version
older than Jun 7, 2019.
Fixes: 4645e3563673 ("selftests/vm/pkeys: rename all references to pkru to a generic name")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org>
---
tools/testing/selftests/vm/protection_keys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/vm/protection_keys.c b/tools/testing/selftests/vm/protection_keys.c
index fc19addcb5c8..fdbb602ecf32 100644
--- a/tools/testing/selftests/vm/protection_keys.c
+++ b/tools/testing/selftests/vm/protection_keys.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Tests Memory Protection Keys (see Documentation/vm/protection-keys.txt)
+ * Tests Memory Protection Keys (see Documentation/core-api/protection-keys.rst)
*
* There are examples in here of:
* * how to set protection keys on memory
--
2.26.2
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
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.
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
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
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
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
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
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
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
When using BPF_PROG_ATTACH to attach a program to a cgroup in
BPF_F_ALLOW_MULTI mode, it is not possible to replace a program
with itself. This is because the check for duplicate programs
doesn't take the replacement program into account.
Replacing a program with itself might seem weird, but it has
some uses: first, it allows resetting the associated cgroup storage.
Second, it makes the API consistent with the non-ALLOW_MULTI usage,
where it is possible to replace a program with itself. Third, it
aligns BPF_PROG_ATTACH with bpf_link, where replacing itself is
also supported.
Sice this code has been refactored a few times this change will
only apply to v5.7 and later. Adjustments could be made to
commit 1020c1f24a94 ("bpf: Simplify __cgroup_bpf_attach") and
commit d7bf2c10af05 ("bpf: allocate cgroup storage entries on attaching bpf programs")
as well as commit 324bda9e6c5a ("bpf: multi program support for cgroup+bpf")
Signed-off-by: Lorenz Bauer <lmb(a)cloudflare.com>
Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment")
---
kernel/bpf/cgroup.c | 2 +-
.../testing/selftests/bpf/prog_tests/cgroup_attach_multi.c | 7 +++++++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index fdf7836750a3..4d76f16524cc 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -378,7 +378,7 @@ static struct bpf_prog_list *find_attach_entry(struct list_head *progs,
}
list_for_each_entry(pl, progs, node) {
- if (prog && pl->prog == prog)
+ if (prog && pl->prog == prog && prog != replace_prog)
/* disallow attaching the same prog twice */
return ERR_PTR(-EINVAL);
if (link && pl->link == link)
diff --git a/tools/testing/selftests/bpf/prog_tests/cgroup_attach_multi.c b/tools/testing/selftests/bpf/prog_tests/cgroup_attach_multi.c
index 139f8e82c7c6..b549fcfacc0b 100644
--- a/tools/testing/selftests/bpf/prog_tests/cgroup_attach_multi.c
+++ b/tools/testing/selftests/bpf/prog_tests/cgroup_attach_multi.c
@@ -230,6 +230,13 @@ void test_cgroup_attach_multi(void)
"prog_replace", "errno=%d\n", errno))
goto err;
+ /* replace program with itself */
+ attach_opts.replace_prog_fd = allow_prog[6];
+ if (CHECK(bpf_prog_attach_xattr(allow_prog[6], cg1,
+ BPF_CGROUP_INET_EGRESS, &attach_opts),
+ "prog_replace", "errno=%d\n", errno))
+ goto err;
+
value = 0;
CHECK_FAIL(bpf_map_update_elem(map_fd, &key, &value, 0));
CHECK_FAIL(system(PING_CMD));
--
2.25.1
Hi Linus,
Please pull the Kunit update for Linux 5.8-rc1.
This Kunit update for Linux 5.8-rc1 consists of:
- Several config fragment fixes from Anders Roxell to improve
test coverage.
- Improvements to kunit run script to use defconfig as default and
restructure the code for config/build/exec/parse from Vitor Massaru Iha
and David Gow.
- Miscellaneous documentation warn fix.
diff is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit 2ef96a5bb12be62ef75b5828c0aab838ebb29cb8:
Linux 5.7-rc5 (2020-05-10 15:16:58 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-kunit-5.8-rc1
for you to fetch changes up to 6d6861d45e38d42a7df9db244c871ee3856acf57:
security: apparmor: default KUNIT_* fragments to KUNIT_ALL_TESTS
(2020-06-01 14:25:15 -0600)
----------------------------------------------------------------
linux-kselftest-kunit-5.8-rc1
This Kunit update for Linux 5.8-rc1 consists of:
- Several config fragment fixes from Anders Roxell to improve
test coverage.
- Improvements to kunit run script to use defconfig as default and
restructure the code for config/build/exec/parse from Vitor Massaru Iha
and David Gow.
- Miscellaneous documentation warn fix.
----------------------------------------------------------------
Anders Roxell (6):
kunit: Kconfig: enable a KUNIT_ALL_TESTS fragment
kunit: default KUNIT_* fragments to KUNIT_ALL_TESTS
lib: Kconfig.debug: default KUNIT_* fragments to KUNIT_ALL_TESTS
drivers: base: default KUNIT_* fragments to KUNIT_ALL_TESTS
fs: ext4: default KUNIT_* fragments to KUNIT_ALL_TESTS
security: apparmor: default KUNIT_* fragments to KUNIT_ALL_TESTS
David Gow (1):
kunit: kunit_tool: Separate out config/build/exec/parse
Lothar Rubusch (1):
Documentation: test.h - fix warnings
Vitor Massaru Iha (3):
kunit: use --build_dir=.kunit as default
kunit: use KUnit defconfig by default
kunit: Fix TabError, remove defconfig code and handle when there
is no kunitconfig
Documentation/dev-tools/kunit/start.rst | 13 +-
Documentation/dev-tools/kunit/usage.rst | 4 +-
drivers/base/Kconfig | 3 +-
drivers/base/test/Kconfig | 3 +-
fs/ext4/Kconfig | 3 +-
include/kunit/test.h | 12 +-
lib/Kconfig.debug | 6 +-
lib/kunit/Kconfig | 23 ++-
security/apparmor/Kconfig | 3 +-
tools/testing/kunit/kunit.py | 307
+++++++++++++++++++++++++-------
tools/testing/kunit/kunit_tool_test.py | 63 ++++++-
11 files changed, 351 insertions(+), 89 deletions(-)
----------------------------------------------------------------
Hi Linus,
Please pull the following Kselftest update for Linux 5.8-rc1.
This Kselftest update for Linux 5.8-rc1 consists of:
- Several fixes from Masami Hiramatsu to improve coverage for
lib and sysctl tests.
- Clean up to vdso test and a new test for getcpu() from Mark Brown.
- Add new gen_tar selftests Makefile target generate selftest package
running "make gen_tar" in selftests directory from Veronika Kabatova.
- Other miscellaneous fixes to timens, exec, tpm2 tests.
diff is attached.
Please note that there is a conflict in
tools/testing/selftests/sysctl/sysctl.sh
between commit:
eee470e0739a ("selftests/sysctl: Fix to load test_sysctl module")
from the kselftest tree and patch:
"tools/testing/selftests/sysctl/sysctl.sh: support CONFIG_TEST_SYSCTL=y"
Stephen fixed this up in linux-next. Masami double checked the fix.
Please let me know if you see any problems and would like me to
address them.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit 2ef96a5bb12be62ef75b5828c0aab838ebb29cb8:
Linux 5.7-rc5 (2020-05-10 15:16:58 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-5.8-rc1
for you to fetch changes up to 382561a0f11c4995d48ab82670412f8d6c418430:
selftests/sysctl: Make sysctl test driver as a module (2020-06-02
10:27:02 -0600)
----------------------------------------------------------------
linux-kselftest-5.8-rc1
This Kselftest update for Linux 5.8-rc1 consists of:
- Several fixes from Masami Hiramatsu to improve coverage for
lib and sysctl tests.
- Clean up to vdso test and a new test for getcpu() from Mark Brown.
- Add new gen_tar selftests Makefile target generate selftest package
running "make gen_tar" in selftests directory from Veronika Kabatova.
- Other miscellaneous fixes to timens, exec, tpm2 tests.
----------------------------------------------------------------
Andrei Vagin (1):
selftests/timens: handle a case when alarm clocks are not supported
Kees Cook (1):
selftests/exec: Verify execve of non-regular files fail
Mark Brown (3):
selftests: vdso: Rename vdso_test to vdso_test_gettimeofday
selftests: vdso: Use a header file to prototype parse_vdso API
selftests: vdso: Add a selftest for vDSO getcpu()
Masami Hiramatsu (6):
selftests/ftrace: Use printf for backslash included command
selftests/ftrace: Return unsupported if no error_log file
lib: Make prime number generator independently selectable
lib: Make test_sysctl initialized as module
selftests/sysctl: Fix to load test_sysctl module
selftests/sysctl: Make sysctl test driver as a module
Nikita Sobolev (1):
Kernel selftests: Add check if TPM devices are supported
Veronika Kabatova (1):
selftests: introduce gen_tar Makefile target
Documentation/dev-tools/kselftest.rst | 23 +++++++++
lib/math/Kconfig | 7 ++-
lib/test_sysctl.c | 2 +-
tools/testing/selftests/Makefile | 9 +++-
tools/testing/selftests/exec/.gitignore | 1 +
tools/testing/selftests/exec/Makefile | 2 +-
tools/testing/selftests/exec/execveat.c | 8 ++++
.../ftrace/test.d/ftrace/tracing-error-log.tc | 2 +
tools/testing/selftests/ftrace/test.d/functions | 8 ++--
.../ftrace/test.d/kprobe/kprobe_syntax_errors.tc | 4 +-
tools/testing/selftests/gen_kselftest_tar.sh | 5 ++
tools/testing/selftests/sysctl/config | 2 +-
tools/testing/selftests/sysctl/sysctl.sh | 13 +-----
tools/testing/selftests/timens/clock_nanosleep.c | 2 +-
tools/testing/selftests/timens/timens.c | 2 +-
tools/testing/selftests/timens/timens.h | 13 +++++-
tools/testing/selftests/timens/timer.c | 5 ++
tools/testing/selftests/timens/timerfd.c | 5 ++
tools/testing/selftests/tpm2/test_smoke.sh | 5 ++
tools/testing/selftests/tpm2/test_space.sh | 5 ++
tools/testing/selftests/vDSO/.gitignore | 2 +
tools/testing/selftests/vDSO/Makefile | 5 +-
tools/testing/selftests/vDSO/parse_vdso.c | 24 +---------
tools/testing/selftests/vDSO/parse_vdso.h | 31 +++++++++++++
.../selftests/vDSO/vdso_standalone_test_x86.c | 4 +-
tools/testing/selftests/vDSO/vdso_test_getcpu.c | 54
++++++++++++++++++++++
.../vDSO/{vdso_test.c => vdso_test_gettimeofday.c} | 10 ++--
27 files changed, 196 insertions(+), 57 deletions(-)
create mode 100644 tools/testing/selftests/vDSO/parse_vdso.h
create mode 100644 tools/testing/selftests/vDSO/vdso_test_getcpu.c
rename tools/testing/selftests/vDSO/{vdso_test.c =>
vdso_test_gettimeofday.c} (84%)
----------------------------------------------------------------
From: Tom Rix <trix(a)redhat.com>
repo : linux-next
tag : next-20200608
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.
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 | 38 +++++++++++++++++++
tools/testing/selftests/drivers/fpga/config | 1 +
4 files changed, 49 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
Currently, drivers can only tell whether the link is up/down,
but no additional information is given.
This patch set provides an infrastructure that allows drivers to expose
to the user more information in addition to the link state.
This information can save users time which will not be wasted
trying to understand why the link is not up for example.
Expand the existing LINKSTATE_GET command with attributes for extended
state.
>From userspace, user can see the extended state like:
$ ethtool ethX
...
Link detected: no (No cable)
In addition, when drivers have another information about the general
extended state, it can be passed also using substate field.
>From userspace:
$ ethtool ethX
...
Link detected: no (Autoneg failure, No partner detected)
In the future the infrastructure can be used for example by PHY drivers to
report whether a downshift to a lower speed occurred, something like:
$ ethtool ethX
...
Link detected: yes (downshifted)
Patches #1-#3 Move mlxsw ethtool code to separate file
Patches #4-#5 Add infrastructure in ethtool
Patches #6-#7 Add support of extended state in mlxsw driver
Patches #8-#10 Add tests cases
Amit Cohen (10):
mlxsw: spectrum_dcb: Rename mlxsw_sp_port_headroom_set()
mlxsw: Move ethtool_ops to spectrum_ethtool.c
mlxsw: spectrum_ethtool: Move mlxsw_sp_port_type_speed_ops structs
ethtool: Add link extended state
Documentation: networking: ethtool-netlink: Add link extended state
mlxsw: reg: Port Diagnostics Database Register
mlxsw: spectrum_ethtool: Add link extended state
selftests: forwarding: ethtool: Move different_speeds_get() to
ethtool_lib
selftests: forwarding: forwarding.config.sample: Add port with no
cable connected
selftests: forwarding: Add tests for ethtool extended state
Documentation/networking/ethtool-netlink.rst | 56 +-
drivers/net/ethernet/mellanox/mlxsw/Makefile | 3 +-
drivers/net/ethernet/mellanox/mlxsw/reg.h | 51 +
.../net/ethernet/mellanox/mlxsw/spectrum.c | 1540 +---------------
.../net/ethernet/mellanox/mlxsw/spectrum.h | 45 +
.../ethernet/mellanox/mlxsw/spectrum_dcb.c | 6 +-
.../mellanox/mlxsw/spectrum_ethtool.c | 1641 +++++++++++++++++
include/linux/ethtool.h | 22 +
include/uapi/linux/ethtool.h | 70 +
include/uapi/linux/ethtool_netlink.h | 2 +
net/ethtool/linkstate.c | 40 +
.../selftests/net/forwarding/ethtool.sh | 17 -
.../net/forwarding/ethtool_extended_state.sh | 103 ++
.../selftests/net/forwarding/ethtool_lib.sh | 17 +
.../net/forwarding/forwarding.config.sample | 3 +
15 files changed, 2057 insertions(+), 1559 deletions(-)
create mode 100644 drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c
create mode 100755 tools/testing/selftests/net/forwarding/ethtool_extended_state.sh
--
2.20.1
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
From: Stanislav Fomichev <sdf(a)google.com>
[ Upstream commit 5366d2269139ba8eb6a906d73a0819947e3e4e0a ]
Commit 294f2fc6da27 ("bpf: Verifer, adjust_scalar_min_max_vals to always
call update_reg_bounds()") changed the way verifier logs some of its state,
adjust the test_align accordingly. Where possible, I tried to not copy-paste
the entire log line and resorted to dropping the last closing brace instead.
Fixes: 294f2fc6da27 ("bpf: Verifer, adjust_scalar_min_max_vals to always call update_reg_bounds()")
Signed-off-by: Stanislav Fomichev <sdf(a)google.com>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
Link: https://lore.kernel.org/bpf/20200515194904.229296-1-sdf@google.com
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/bpf/test_align.c | 41 ++++++++++++------------
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_align.c b/tools/testing/selftests/bpf/test_align.c
index 0262f7b374f9..c9c9bdce9d6d 100644
--- a/tools/testing/selftests/bpf/test_align.c
+++ b/tools/testing/selftests/bpf/test_align.c
@@ -359,15 +359,15 @@ static struct bpf_align_test tests[] = {
* is still (4n), fixed offset is not changed.
* Also, we create a new reg->id.
*/
- {29, "R5_w=pkt(id=4,off=18,r=0,umax_value=2040,var_off=(0x0; 0x7fc))"},
+ {29, "R5_w=pkt(id=4,off=18,r=0,umax_value=2040,var_off=(0x0; 0x7fc)"},
/* At the time the word size load is performed from R5,
* its total fixed offset is NET_IP_ALIGN + reg->off (18)
* which is 20. Then the variable offset is (4n), so
* the total offset is 4-byte aligned and meets the
* load's requirements.
*/
- {33, "R4=pkt(id=4,off=22,r=22,umax_value=2040,var_off=(0x0; 0x7fc))"},
- {33, "R5=pkt(id=4,off=18,r=22,umax_value=2040,var_off=(0x0; 0x7fc))"},
+ {33, "R4=pkt(id=4,off=22,r=22,umax_value=2040,var_off=(0x0; 0x7fc)"},
+ {33, "R5=pkt(id=4,off=18,r=22,umax_value=2040,var_off=(0x0; 0x7fc)"},
},
},
{
@@ -410,15 +410,15 @@ static struct bpf_align_test tests[] = {
/* Adding 14 makes R6 be (4n+2) */
{9, "R6_w=inv(id=0,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc))"},
/* Packet pointer has (4n+2) offset */
- {11, "R5_w=pkt(id=1,off=0,r=0,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc))"},
- {13, "R4=pkt(id=1,off=4,r=0,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc))"},
+ {11, "R5_w=pkt(id=1,off=0,r=0,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc)"},
+ {13, "R4=pkt(id=1,off=4,r=0,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc)"},
/* At the time the word size load is performed from R5,
* its total fixed offset is NET_IP_ALIGN + reg->off (0)
* which is 2. Then the variable offset is (4n+2), so
* the total offset is 4-byte aligned and meets the
* load's requirements.
*/
- {15, "R5=pkt(id=1,off=0,r=4,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc))"},
+ {15, "R5=pkt(id=1,off=0,r=4,umin_value=14,umax_value=1034,var_off=(0x2; 0x7fc)"},
/* Newly read value in R6 was shifted left by 2, so has
* known alignment of 4.
*/
@@ -426,15 +426,15 @@ static struct bpf_align_test tests[] = {
/* Added (4n) to packet pointer's (4n+2) var_off, giving
* another (4n+2).
*/
- {19, "R5_w=pkt(id=2,off=0,r=0,umin_value=14,umax_value=2054,var_off=(0x2; 0xffc))"},
- {21, "R4=pkt(id=2,off=4,r=0,umin_value=14,umax_value=2054,var_off=(0x2; 0xffc))"},
+ {19, "R5_w=pkt(id=2,off=0,r=0,umin_value=14,umax_value=2054,var_off=(0x2; 0xffc)"},
+ {21, "R4=pkt(id=2,off=4,r=0,umin_value=14,umax_value=2054,var_off=(0x2; 0xffc)"},
/* At the time the word size load is performed from R5,
* its total fixed offset is NET_IP_ALIGN + reg->off (0)
* which is 2. Then the variable offset is (4n+2), so
* the total offset is 4-byte aligned and meets the
* load's requirements.
*/
- {23, "R5=pkt(id=2,off=0,r=4,umin_value=14,umax_value=2054,var_off=(0x2; 0xffc))"},
+ {23, "R5=pkt(id=2,off=0,r=4,umin_value=14,umax_value=2054,var_off=(0x2; 0xffc)"},
},
},
{
@@ -469,16 +469,16 @@ static struct bpf_align_test tests[] = {
.matches = {
{4, "R5_w=pkt_end(id=0,off=0,imm=0)"},
/* (ptr - ptr) << 2 == unknown, (4n) */
- {6, "R5_w=inv(id=0,smax_value=9223372036854775804,umax_value=18446744073709551612,var_off=(0x0; 0xfffffffffffffffc))"},
+ {6, "R5_w=inv(id=0,smax_value=9223372036854775804,umax_value=18446744073709551612,var_off=(0x0; 0xfffffffffffffffc)"},
/* (4n) + 14 == (4n+2). We blow our bounds, because
* the add could overflow.
*/
- {7, "R5_w=inv(id=0,var_off=(0x2; 0xfffffffffffffffc))"},
+ {7, "R5_w=inv(id=0,smin_value=-9223372036854775806,smax_value=9223372036854775806,umin_value=2,umax_value=18446744073709551614,var_off=(0x2; 0xfffffffffffffffc)"},
/* Checked s>=0 */
- {9, "R5=inv(id=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
+ {9, "R5=inv(id=0,umin_value=2,umax_value=9223372034707292158,var_off=(0x2; 0x7fffffff7ffffffc)"},
/* packet pointer + nonnegative (4n+2) */
- {11, "R6_w=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
- {13, "R4_w=pkt(id=1,off=4,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
+ {11, "R6_w=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372034707292158,var_off=(0x2; 0x7fffffff7ffffffc)"},
+ {13, "R4_w=pkt(id=1,off=4,r=0,umin_value=2,umax_value=9223372034707292158,var_off=(0x2; 0x7fffffff7ffffffc)"},
/* NET_IP_ALIGN + (4n+2) == (4n), alignment is fine.
* We checked the bounds, but it might have been able
* to overflow if the packet pointer started in the
@@ -486,7 +486,7 @@ static struct bpf_align_test tests[] = {
* So we did not get a 'range' on R6, and the access
* attempt will fail.
*/
- {15, "R6_w=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
+ {15, "R6_w=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372034707292158,var_off=(0x2; 0x7fffffff7ffffffc)"},
}
},
{
@@ -528,7 +528,7 @@ static struct bpf_align_test tests[] = {
/* New unknown value in R7 is (4n) */
{11, "R7_w=inv(id=0,umax_value=1020,var_off=(0x0; 0x3fc))"},
/* Subtracting it from R6 blows our unsigned bounds */
- {12, "R6=inv(id=0,smin_value=-1006,smax_value=1034,var_off=(0x2; 0xfffffffffffffffc))"},
+ {12, "R6=inv(id=0,smin_value=-1006,smax_value=1034,umin_value=2,umax_value=18446744073709551614,var_off=(0x2; 0xfffffffffffffffc)"},
/* Checked s>= 0 */
{14, "R6=inv(id=0,umin_value=2,umax_value=1034,var_off=(0x2; 0x7fc))"},
/* At the time the word size load is performed from R5,
@@ -537,7 +537,8 @@ static struct bpf_align_test tests[] = {
* the total offset is 4-byte aligned and meets the
* load's requirements.
*/
- {20, "R5=pkt(id=1,off=0,r=4,umin_value=2,umax_value=1034,var_off=(0x2; 0x7fc))"},
+ {20, "R5=pkt(id=1,off=0,r=4,umin_value=2,umax_value=1034,var_off=(0x2; 0x7fc)"},
+
},
},
{
@@ -579,18 +580,18 @@ static struct bpf_align_test tests[] = {
/* Adding 14 makes R6 be (4n+2) */
{11, "R6_w=inv(id=0,umin_value=14,umax_value=74,var_off=(0x2; 0x7c))"},
/* Subtracting from packet pointer overflows ubounds */
- {13, "R5_w=pkt(id=1,off=0,r=8,umin_value=18446744073709551542,umax_value=18446744073709551602,var_off=(0xffffffffffffff82; 0x7c))"},
+ {13, "R5_w=pkt(id=1,off=0,r=8,umin_value=18446744073709551542,umax_value=18446744073709551602,var_off=(0xffffffffffffff82; 0x7c)"},
/* New unknown value in R7 is (4n), >= 76 */
{15, "R7_w=inv(id=0,umin_value=76,umax_value=1096,var_off=(0x0; 0x7fc))"},
/* Adding it to packet pointer gives nice bounds again */
- {16, "R5_w=pkt(id=2,off=0,r=0,umin_value=2,umax_value=1082,var_off=(0x2; 0x7fc))"},
+ {16, "R5_w=pkt(id=2,off=0,r=0,umin_value=2,umax_value=1082,var_off=(0x2; 0xfffffffc)"},
/* At the time the word size load is performed from R5,
* its total fixed offset is NET_IP_ALIGN + reg->off (0)
* which is 2. Then the variable offset is (4n+2), so
* the total offset is 4-byte aligned and meets the
* load's requirements.
*/
- {20, "R5=pkt(id=2,off=0,r=4,umin_value=2,umax_value=1082,var_off=(0x2; 0x7fc))"},
+ {20, "R5=pkt(id=2,off=0,r=4,umin_value=2,umax_value=1082,var_off=(0x2; 0xfffffffc)"},
},
},
};
--
2.25.1
From: Peter Xu <peterx(a)redhat.com>
[ Upstream commit 8ffdaf9155ebe517cdec5edbcca19ba6e7ee9c3c ]
I got this error when building kvm selftests:
/usr/bin/ld: /home/xz/git/linux/tools/testing/selftests/kvm/libkvm.a(vmx.o):/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:222: multiple definition of `current_evmcs'; /tmp/cco1G48P.o:/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:222: first defined here
/usr/bin/ld: /home/xz/git/linux/tools/testing/selftests/kvm/libkvm.a(vmx.o):/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:223: multiple definition of `current_vp_assist'; /tmp/cco1G48P.o:/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:223: first defined here
I think it's because evmcs.h is included both in a test file and a lib file so
the structs have multiple declarations when linking. After all it's not a good
habit to declare structs in the header files.
Cc: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Signed-off-by: Peter Xu <peterx(a)redhat.com>
Message-Id: <20200504220607.99627-1-peterx(a)redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/kvm/include/evmcs.h | 4 ++--
tools/testing/selftests/kvm/lib/x86_64/vmx.c | 3 +++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/kvm/include/evmcs.h b/tools/testing/selftests/kvm/include/evmcs.h
index 4912d23844bc..e31ac9c5ead0 100644
--- a/tools/testing/selftests/kvm/include/evmcs.h
+++ b/tools/testing/selftests/kvm/include/evmcs.h
@@ -217,8 +217,8 @@ struct hv_enlightened_vmcs {
#define HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_MASK \
(~((1ull << HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT) - 1))
-struct hv_enlightened_vmcs *current_evmcs;
-struct hv_vp_assist_page *current_vp_assist;
+extern struct hv_enlightened_vmcs *current_evmcs;
+extern struct hv_vp_assist_page *current_vp_assist;
int vcpu_enable_evmcs(struct kvm_vm *vm, int vcpu_id);
diff --git a/tools/testing/selftests/kvm/lib/x86_64/vmx.c b/tools/testing/selftests/kvm/lib/x86_64/vmx.c
index 7aaa99ca4dbc..ce528f3cf093 100644
--- a/tools/testing/selftests/kvm/lib/x86_64/vmx.c
+++ b/tools/testing/selftests/kvm/lib/x86_64/vmx.c
@@ -17,6 +17,9 @@
bool enable_evmcs;
+struct hv_enlightened_vmcs *current_evmcs;
+struct hv_vp_assist_page *current_vp_assist;
+
struct eptPageTableEntry {
uint64_t readable:1;
uint64_t writable:1;
--
2.25.1
From: Shuah Khan <skhan(a)linuxfoundation.org>
[ Upstream commit 66d69e081b526b6a6031f0d3ca8ddff71e5707a5 ]
kvm test Makefile doesn't fully support cross-builds and installs.
UNAME_M = $(shell uname -m) variable is used to define the target
programs and libraries to be built from arch specific sources in
sub-directories.
For cross-builds to work, UNAME_M has to map to ARCH and arch specific
directories and targets in this Makefile.
UNAME_M variable to used to run the compiles pointing to the right arch
directories and build the right targets for these supported architectures.
TEST_GEN_PROGS and LIBKVM are set using UNAME_M variable.
LINUX_TOOL_ARCH_INCLUDE is set using ARCH variable.
x86_64 targets are named to include x86_64 as a suffix and directories
for includes are in x86_64 sub-directory. s390x and aarch64 follow the
same convention. "uname -m" doesn't result in the correct mapping for
s390x and aarch64. Fix it to set UNAME_M correctly for s390x and aarch64
cross-builds.
In addition, Makefile doesn't create arch sub-directories in the case of
relocatable builds and test programs under s390x and x86_64 directories
fail to build. This is a problem for native and cross-builds. Fix it to
create all necessary directories keying off of TEST_GEN_PROGS.
The following use-cases work with this change:
Native x86_64:
make O=/tmp/kselftest -C tools/testing/selftests TARGETS=kvm install \
INSTALL_PATH=$HOME/x86_64
arm64 cross-build:
make O=$HOME/arm64_build/ ARCH=arm64 HOSTCC=gcc \
CROSS_COMPILE=aarch64-linux-gnu- defconfig
make O=$HOME/arm64_build/ ARCH=arm64 HOSTCC=gcc \
CROSS_COMPILE=aarch64-linux-gnu- all
make kselftest-install TARGETS=kvm O=$HOME/arm64_build ARCH=arm64 \
HOSTCC=gcc CROSS_COMPILE=aarch64-linux-gnu-
s390x cross-build:
make O=$HOME/s390x_build/ ARCH=s390 HOSTCC=gcc \
CROSS_COMPILE=s390x-linux-gnu- defconfig
make O=$HOME/s390x_build/ ARCH=s390 HOSTCC=gcc \
CROSS_COMPILE=s390x-linux-gnu- all
make kselftest-install TARGETS=kvm O=$HOME/s390x_build/ ARCH=s390 \
HOSTCC=gcc CROSS_COMPILE=s390x-linux-gnu- all
No regressions in the following use-cases:
make -C tools/testing/selftests TARGETS=kvm
make kselftest-all TARGETS=kvm
Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/kvm/Makefile | 29 +++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
index d91c53b726e6..75dec268787f 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -5,8 +5,34 @@ all:
top_srcdir = ../../../..
KSFT_KHDR_INSTALL := 1
+
+# For cross-builds to work, UNAME_M has to map to ARCH and arch specific
+# directories and targets in this Makefile. "uname -m" doesn't map to
+# arch specific sub-directory names.
+#
+# UNAME_M variable to used to run the compiles pointing to the right arch
+# directories and build the right targets for these supported architectures.
+#
+# TEST_GEN_PROGS and LIBKVM are set using UNAME_M variable.
+# LINUX_TOOL_ARCH_INCLUDE is set using ARCH variable.
+#
+# x86_64 targets are named to include x86_64 as a suffix and directories
+# for includes are in x86_64 sub-directory. s390x and aarch64 follow the
+# same convention. "uname -m" doesn't result in the correct mapping for
+# s390x and aarch64.
+#
+# No change necessary for x86_64
UNAME_M := $(shell uname -m)
+# Set UNAME_M for arm64 compile/install to work
+ifeq ($(ARCH),arm64)
+ UNAME_M := aarch64
+endif
+# Set UNAME_M s390x compile/install to work
+ifeq ($(ARCH),s390)
+ UNAME_M := s390x
+endif
+
LIBKVM = lib/assert.c lib/elf.c lib/io.c lib/kvm_util.c lib/sparsebit.c
LIBKVM_x86_64 = lib/x86_64/processor.c lib/x86_64/vmx.c lib/x86_64/svm.c lib/x86_64/ucall.c
LIBKVM_aarch64 = lib/aarch64/processor.c lib/aarch64/ucall.c
@@ -47,7 +73,7 @@ LIBKVM += $(LIBKVM_$(UNAME_M))
INSTALL_HDR_PATH = $(top_srcdir)/usr
LINUX_HDR_PATH = $(INSTALL_HDR_PATH)/include/
LINUX_TOOL_INCLUDE = $(top_srcdir)/tools/include
-LINUX_TOOL_ARCH_INCLUDE = $(top_srcdir)/tools/arch/x86/include
+LINUX_TOOL_ARCH_INCLUDE = $(top_srcdir)/tools/arch/$(ARCH)/include
CFLAGS += -Wall -Wstrict-prototypes -Wuninitialized -O2 -g -std=gnu99 \
-fno-stack-protector -fno-PIE -I$(LINUX_TOOL_INCLUDE) \
-I$(LINUX_TOOL_ARCH_INCLUDE) -I$(LINUX_HDR_PATH) -Iinclude \
@@ -78,6 +104,7 @@ $(LIBKVM_OBJ): $(OUTPUT)/%.o: %.c
$(OUTPUT)/libkvm.a: $(LIBKVM_OBJ)
$(AR) crs $@ $^
+x := $(shell mkdir -p $(sort $(dir $(TEST_GEN_PROGS))))
all: $(STATIC_LIBS)
$(TEST_GEN_PROGS): $(STATIC_LIBS)
--
2.25.1
From: Alan Maguire <alan.maguire(a)oracle.com>
[ Upstream commit b730d668138cb3dd9ce78f8003986d1adae5523a ]
Currently, ftracetest will return 1 (failure) if any unresolved cases
are encountered. The unresolved status results from modules and
programs not being available, and as such does not indicate any
issues with ftrace itself. As such, change the behaviour of
ftracetest in line with unsupported cases; if unsupported cases
happen, ftracetest still returns 0 unless --fail-unsupported. Here
--fail-unresolved is added and the default is to return 0 if
unresolved results occur.
Signed-off-by: Alan Maguire <alan.maguire(a)oracle.com>
Acked-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Acked-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/ftrace/ftracetest | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ftrace/ftracetest b/tools/testing/selftests/ftrace/ftracetest
index 144308a757b7..19e9236dec5e 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -17,6 +17,7 @@ echo " -v|--verbose Increase verbosity of test messages"
echo " -vv Alias of -v -v (Show all results in stdout)"
echo " -vvv Alias of -v -v -v (Show all commands immediately)"
echo " --fail-unsupported Treat UNSUPPORTED as a failure"
+echo " --fail-unresolved Treat UNRESOLVED as a failure"
echo " -d|--debug Debug mode (trace all shell commands)"
echo " -l|--logdir <dir> Save logs on the <dir>"
echo " If <dir> is -, all logs output in console only"
@@ -112,6 +113,10 @@ parse_opts() { # opts
UNSUPPORTED_RESULT=1
shift 1
;;
+ --fail-unresolved)
+ UNRESOLVED_RESULT=1
+ shift 1
+ ;;
--logdir|-l)
LOG_DIR=$2
shift 2
@@ -176,6 +181,7 @@ KEEP_LOG=0
DEBUG=0
VERBOSE=0
UNSUPPORTED_RESULT=0
+UNRESOLVED_RESULT=0
STOP_FAILURE=0
# Parse command-line options
parse_opts $*
@@ -280,7 +286,7 @@ eval_result() { # sigval
$UNRESOLVED)
prlog " [${color_blue}UNRESOLVED${color_reset}]"
UNRESOLVED_CASES="$UNRESOLVED_CASES $CASENO"
- return 1 # this is a kind of bug.. something happened.
+ return $UNRESOLVED_RESULT # depends on use case
;;
$UNTESTED)
prlog " [${color_blue}UNTESTED${color_reset}]"
--
2.25.1
v2:
- drop completion variables and flush workqueue [pmladek]
- comment typo/pr_info cleanup [kbabulal/mbenes]
- cleanup goto ret assignations [pmladek]
- allocate pndup[]'s, leave some svar allocations to
shadow_get_or_alloc() [pmladek]
- change allocation order for cleaner test dmesg output [pmladek]
The test-klp-callbacks change implements a synchronization replacement of
initial code which relied on solely on sleep delays. Remove the sleeps
and pass a block_transition flag from test script to module. Use
flush_workqueue() to serialize module output for test result
consideration.
The test-klp-shadow-vars changes first refactors the code to be more of
a readable example as well as continuing to verify the component code.
The patch is broken in two to display the renaming and restructuring in
part 1 and the addition and change of logic in part 2. The last change
frees memory before bailing in case of errors.
Patchset to be merged via the livepatching tree is against: livepatching/for-next
Joe Lawrence (1):
selftests/livepatch: simplify test-klp-callbacks busy target tests
Yannick Cote (3):
selftests/livepatch: rework test-klp-shadow-vars
selftests/livepatch: more verification in test-klp-shadow-vars
selftests/livepatch: fix mem leaks in test-klp-shadow-vars
lib/livepatch/test_klp_callbacks_busy.c | 37 ++-
lib/livepatch/test_klp_shadow_vars.c | 240 ++++++++++--------
.../selftests/livepatch/test-callbacks.sh | 29 +--
.../selftests/livepatch/test-shadow-vars.sh | 81 +++---
4 files changed, 225 insertions(+), 162 deletions(-)
--
2.25.4
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 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/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 +
22 files changed, 4595 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
Hi,
Here is the 2nd version of the series of "requires:" list for
simplifying and unifying requirement checks for each test case.
The previous version is here.
https://lkml.kernel.org/r/159102252279.31199.12855129586058455119.stgit@dev…
I've fixed some trival mistakes and add Tom's reviewed-by
in this version.
Currently, we have many similar requirement checker to find
unconfigured or unsupported (in older kernels) feature in
each test case. I think it is a good time to unify those similar
checks.
As same as "description:" or "flags:" line, this series introduces
new "requires:" line, and convert current checking code intor the
"requires:" line.
This requires line gives some good effects, not only simplyfies
the code, but also unifies the reason message, and because it checks
the requirements before running the testc ase, it skips unneeded
ftrace initialization.
The requires line supports following checks
- tracefs interface check: Check whether the given file or directory
in the tracefs. (No suffix) [3/7],[4/7],[5/7]
- available tracer check: Check whether the given tracer is available
(":tracer" suffix) [6/7]
- README feature check: Check whether the given string is in the
README (":README" suffix) [7/7]
This series also includes the description line fix and
unresolved -> unsupported change ([1/7] and [2/7]).
Note: Since the requires line returns UNSUPPORTED error,
the requirements must be one of ftrace feature, but not the
user-space environmental requirement. If there is some issue
in user-space (e.g. lack of the command, modules, etc) it must
report UNRESOLVED error.
Since this series depends on following 2 commits,
commit 619ee76f5c9f ("selftests/ftrace: Return unsupported if no
error_log file") on Shuah's Kselftest tree
commit bea24f766efc ("selftests/ftrace: Distinguish between hist
and synthetic event checks") on Steven's Tracing tree
This can be applied on the tree which merged both of them.
Also, you can get the series from the following.
git://git.kernel.org/pub/scm/linux/kernel/git/mhiramat/linux.git ftracetest-requires-v2
Thank you,
---
Masami Hiramatsu (7):
selftests/ftrace: Allow ":" in description
selftests/ftrace: Return unsupported for the unconfigured features
selftests/ftrace: Add "requires:" list support
selftests/ftrace: Convert required interface checks into requires list
selftests/ftrace: Convert check_filter_file() with requires list
selftests/ftrace: Support ":tracer" suffix for requires
selftests/ftrace: Support ":README" suffix for requires
tools/testing/selftests/ftrace/ftracetest | 11 ++++++-
.../selftests/ftrace/test.d/00basic/snapshot.tc | 3 +-
.../selftests/ftrace/test.d/00basic/trace_pipe.tc | 3 +-
.../ftrace/test.d/direct/kprobe-direct.tc | 6 +---
.../ftrace/test.d/dynevent/add_remove_kprobe.tc | 6 +---
.../ftrace/test.d/dynevent/add_remove_synth.tc | 5 +--
.../ftrace/test.d/dynevent/clear_select_events.tc | 11 +------
.../ftrace/test.d/dynevent/generic_clear_event.tc | 8 +----
.../selftests/ftrace/test.d/event/event-enable.tc | 6 +---
.../selftests/ftrace/test.d/event/event-no-pid.tc | 11 +------
.../selftests/ftrace/test.d/event/event-pid.tc | 11 +------
.../ftrace/test.d/event/subsystem-enable.tc | 6 +---
.../ftrace/test.d/event/toplevel-enable.tc | 6 +---
.../ftrace/test.d/ftrace/fgraph-filter-stack.tc | 14 +--------
.../ftrace/test.d/ftrace/fgraph-filter.tc | 8 +----
.../ftrace/test.d/ftrace/func-filter-glob.tc | 8 +----
.../test.d/ftrace/func-filter-notrace-pid.tc | 13 +-------
.../ftrace/test.d/ftrace/func-filter-pid.tc | 13 +-------
.../ftrace/test.d/ftrace/func-filter-stacktrace.tc | 3 +-
.../selftests/ftrace/test.d/ftrace/func_cpumask.tc | 6 +---
.../ftrace/test.d/ftrace/func_event_triggers.tc | 7 ++---
.../ftrace/test.d/ftrace/func_mod_trace.tc | 3 +-
.../ftrace/test.d/ftrace/func_profile_stat.tc | 3 +-
.../ftrace/test.d/ftrace/func_profiler.tc | 12 +-------
.../ftrace/test.d/ftrace/func_set_ftrace_file.tc | 6 ++--
.../ftrace/test.d/ftrace/func_stack_tracer.tc | 8 +----
.../test.d/ftrace/func_traceonoff_triggers.tc | 6 ++--
.../ftrace/test.d/ftrace/tracing-error-log.tc | 12 ++------
tools/testing/selftests/ftrace/test.d/functions | 28 ++++++++++++++----
.../ftrace/test.d/instances/instance-event.tc | 6 +---
.../selftests/ftrace/test.d/instances/instance.tc | 6 +---
.../ftrace/test.d/kprobe/add_and_remove.tc | 3 +-
.../selftests/ftrace/test.d/kprobe/busy_check.tc | 3 +-
.../selftests/ftrace/test.d/kprobe/kprobe_args.tc | 3 +-
.../ftrace/test.d/kprobe/kprobe_args_comm.tc | 3 +-
.../ftrace/test.d/kprobe/kprobe_args_string.tc | 3 +-
.../ftrace/test.d/kprobe/kprobe_args_symbol.tc | 3 +-
.../ftrace/test.d/kprobe/kprobe_args_syntax.tc | 5 +--
.../ftrace/test.d/kprobe/kprobe_args_type.tc | 5 +--
.../ftrace/test.d/kprobe/kprobe_args_user.tc | 4 +--
.../ftrace/test.d/kprobe/kprobe_eventname.tc | 3 +-
.../ftrace/test.d/kprobe/kprobe_ftrace.tc | 6 +---
.../ftrace/test.d/kprobe/kprobe_module.tc | 3 +-
.../ftrace/test.d/kprobe/kprobe_multiprobe.tc | 5 +--
.../ftrace/test.d/kprobe/kprobe_syntax_errors.tc | 5 +--
.../ftrace/test.d/kprobe/kretprobe_args.tc | 3 +-
.../ftrace/test.d/kprobe/kretprobe_maxactive.tc | 4 +--
.../ftrace/test.d/kprobe/multiple_kprobes.tc | 3 +-
.../selftests/ftrace/test.d/kprobe/probepoint.tc | 3 +-
.../selftests/ftrace/test.d/kprobe/profile.tc | 3 +-
.../ftrace/test.d/kprobe/uprobe_syntax_errors.tc | 5 +--
.../ftrace/test.d/preemptirq/irqsoff_tracer.tc | 4 +--
tools/testing/selftests/ftrace/test.d/template | 4 +++
.../selftests/ftrace/test.d/tracer/wakeup.tc | 6 +---
.../selftests/ftrace/test.d/tracer/wakeup_rt.tc | 6 +---
.../inter-event/trigger-action-hist-xfail.tc | 13 +-------
.../inter-event/trigger-field-variable-support.tc | 16 +---------
.../trigger-inter-event-combined-hist.tc | 16 +---------
.../inter-event/trigger-multi-actions-accept.tc | 16 +---------
.../inter-event/trigger-onchange-action-hist.tc | 8 +----
.../inter-event/trigger-onmatch-action-hist.tc | 16 +---------
.../trigger-onmatch-onmax-action-hist.tc | 16 +---------
.../inter-event/trigger-onmax-action-hist.tc | 16 +---------
.../inter-event/trigger-snapshot-action-hist.tc | 20 +------------
.../trigger-synthetic-event-createremove.tc | 11 +------
.../inter-event/trigger-synthetic-event-syntax.tc | 11 +------
.../inter-event/trigger-trace-action-hist.tc | 18 +-----------
.../ftrace/test.d/trigger/trigger-eventonoff.tc | 11 +------
.../ftrace/test.d/trigger/trigger-filter.tc | 11 +------
.../ftrace/test.d/trigger/trigger-hist-mod.tc | 16 +---------
.../test.d/trigger/trigger-hist-syntax-errors.tc | 18 +-----------
.../ftrace/test.d/trigger/trigger-hist.tc | 16 +---------
.../ftrace/test.d/trigger/trigger-multihist.tc | 16 +---------
.../ftrace/test.d/trigger/trigger-snapshot.tc | 16 +---------
.../ftrace/test.d/trigger/trigger-stacktrace.tc | 11 +------
.../test.d/trigger/trigger-trace-marker-hist.tc | 21 +-------------
.../trigger/trigger-trace-marker-snapshot.tc | 21 +-------------
.../trigger-trace-marker-synthetic-kernel.tc | 31 +-------------------
.../trigger/trigger-trace-marker-synthetic.tc | 26 +----------------
.../ftrace/test.d/trigger/trigger-traceonoff.tc | 11 +------
80 files changed, 119 insertions(+), 633 deletions(-)
--
Masami Hiramatsu (Linaro) <mhiramat(a)kernel.org>
Add an FAQ entry to the KUnit documentation with some tips for
troubleshooting KUnit and kunit_tool.
These suggestions largely came from an email thread:
https://lore.kernel.org/linux-kselftest/41db8bbd-3ba0-8bde-7352-083bf4b947f…
Signed-off-by: David Gow <davidgow(a)google.com>
Reviewed-by: Alan Maguire <alan.maguire(a)oracle.com>
Reviewed-by: Brendan Higgins <brendanhiggins(a)google.com>
---
Changes since v1[1]
- Added a section about running KUnit outside UML (based heavily on
Alan's suggestion in the thread).
[1]: https://lore.kernel.org/linux-kselftest/20200602054216.93122-1-davidgow@goo…
Documentation/dev-tools/kunit/faq.rst | 40 +++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/Documentation/dev-tools/kunit/faq.rst b/Documentation/dev-tools/kunit/faq.rst
index ea55b2467653..1628862e7024 100644
--- a/Documentation/dev-tools/kunit/faq.rst
+++ b/Documentation/dev-tools/kunit/faq.rst
@@ -61,3 +61,43 @@ test, or an end-to-end test.
kernel by installing a production configuration of the kernel on production
hardware with a production userspace and then trying to exercise some behavior
that depends on interactions between the hardware, the kernel, and userspace.
+
+KUnit isn't working, what should I do?
+======================================
+
+Unfortunately, there are a number of things which can break, but here are some
+things to try.
+
+1. Try running ``./tools/testing/kunit/kunit.py run`` with the ``--raw_output``
+ parameter. This might show details or error messages hidden by the kunit_tool
+ parser.
+2. Instead of running ``kunit.py run``, try running ``kunit.py config``,
+ ``kunit.py build``, and ``kunit.py exec`` independently. This can help track
+ down where an issue is occurring. (If you think the parser is at fault, you
+ can run it manually against stdin or a file with ``kunit.py parse``.)
+3. Running the UML kernel directly can often reveal issues or error messages
+ kunit_tool ignores. This should be as simple as running ``./vmlinux`` after
+ building the UML kernel (e.g., by using ``kunit.py build``). Note that UML
+ has some unusual requirements (such as the host having a tmpfs filesystem
+ mounted), and has had issues in the past when built statically and the host
+ has KASLR enabled. (On older host kernels, you may need to run ``setarch
+ `uname -m` -R ./vmlinux`` to disable KASLR.)
+4. Make sure the kernel .config has ``CONFIG_KUNIT=y`` and at least one test
+ (e.g. ``CONFIG_KUNIT_EXAMPLE_TEST=y``). kunit_tool will keep its .config
+ around, so you can see what config was used after running ``kunit.py run``.
+ It also preserves any config changes you might make, so you can
+ enable/disable things with ``make ARCH=um menuconfig`` or similar, and then
+ re-run kunit_tool.
+5. Try to run ``make ARCH=um defconfig`` before running ``kunit.py run``. This
+ may help clean up any residual config items which could be causing problems.
+6. Finally, try running KUnit outside UML. KUnit and KUnit tests can run be
+ built into any kernel, or can be built as a module and loaded at runtime.
+ Doing so should allow you to determine if UML is causing the issue you're
+ seeing. When tests are built-in, they will execute when the kernel boots, and
+ modules will automatically execute associated tests when loaded. Test results
+ can be collected from ``/sys/kernel/debug/kunit/<test suite>/results``, and
+ can be parsed with ``kunit.py parse``. For more details, see "KUnit on
+ non-UML architectures" in :doc:`usage`.
+
+If none of the above tricks help, you are always welcome to email any issues to
+kunit-dev(a)googlegroups.com.
--
2.27.0.rc2.251.g90737beb825-goog
The identation before this code (`if not os.path.exists(cli_args.build_dir):``)
was with spaces instead of tabs after fixed up merge conflits,
this commit revert spaces to tabs:
[iha@bbking linux]$ tools/testing/kunit/kunit.py run
File "tools/testing/kunit/kunit.py", line 247
if not linux:
^
TabError: inconsistent use of tabs and spaces in indentation
Remove defconfig related code to fix these two errors,
the commit 9bdf64b35 was created before 45ba7a893ad,
and the commit 9bdf64b35 removes defconfig related code:
[iha@bbking linux]$ tools/testing/kunit/kunit.py run
Traceback (most recent call last):
File "tools/testing/kunit/kunit.py", line 338, in <module>
main(sys.argv[1:])
File "tools/testing/kunit/kunit.py", line 215, in main
add_config_opts(config_parser)
[iha@bbking linux]$ tools/testing/kunit/kunit.py run
Traceback (most recent call last):
File "tools/testing/kunit/kunit.py", line 337, in <module>
main(sys.argv[1:])
File "tools/testing/kunit/kunit.py", line 255, in main
result = run_tests(linux, request)
File "tools/testing/kunit/kunit.py", line 133, in run_tests
request.defconfig,
AttributeError: 'KunitRequest' object has no attribute 'defconfig'
Handles when there is no .kunitconfig, the error occurs because
commit 9bdf64b35 was created before 45ba7a893ad.
[iha@bbking linux]$ tools/testing/kunit/kunit.py run
Traceback (most recent call last):
File "tools/testing/kunit/kunit.py", line 335, in <module>
main(sys.argv[1:])
File "tools/testing/kunit/kunit.py", line 246, in main
linux = kunit_kernel.LinuxSourceTree()
File "/home/iha/sdb/opensource/lkmp/linux/tools/testing/kunit/kunit_kernel.py", line 109, in __init__
self._kconfig.read_from_file(kunitconfig_path)
File "/home/iha/sdb/opensource/lkmp/linux/tools/testing/kunit/kunit_config.py", line 88, in read_from_file
with open(path, 'r') as f:
FileNotFoundError: [Errno 2] No such file or directory: '.kunit/.kunitconfig'
Signed-off-by: Vitor Massaru Iha <vitor(a)massaru.org>
---
Fix the fixup on this commits: 9bdf64b, ddbd60c.
Some errors occurs because these commits were created before
this commit 45ba7a8, as explained in the commit message.
---
tools/testing/kunit/kunit.py | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py
index ec73b07d1265..787b6d4ad716 100755
--- a/tools/testing/kunit/kunit.py
+++ b/tools/testing/kunit/kunit.py
@@ -23,7 +23,7 @@ import kunit_parser
KunitResult = namedtuple('KunitResult', ['status','result','elapsed_time'])
KunitConfigRequest = namedtuple('KunitConfigRequest',
- ['build_dir', 'defconfig', 'make_options'])
+ ['build_dir', 'make_options'])
KunitBuildRequest = namedtuple('KunitBuildRequest',
['jobs', 'build_dir', 'alltests',
'make_options'])
@@ -130,7 +130,6 @@ def run_tests(linux: kunit_kernel.LinuxSourceTree,
run_start = time.time()
config_request = KunitConfigRequest(request.build_dir,
- request.defconfig,
request.make_options)
config_result = config_tests(linux, config_request)
if config_result.status != KunitStatus.SUCCESS:
@@ -212,7 +211,6 @@ def main(argv, linux=None):
help='Ensures that .config contains all of '
'the options in .kunitconfig')
add_common_opts(config_parser)
- add_config_opts(config_parser)
build_parser = subparser.add_parser('build', help='Builds a kernel with KUnit tests')
add_common_opts(build_parser)
@@ -238,11 +236,14 @@ def main(argv, linux=None):
cli_args = parser.parse_args(argv)
if cli_args.subcommand == 'run':
- 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 os.path.exists(kunit_kernel.kunitconfig_path):
+ create_default_kunitconfig()
if not linux:
linux = kunit_kernel.LinuxSourceTree()
@@ -264,11 +265,13 @@ def main(argv, linux=None):
cli_args.build_dir,
kunit_kernel.kunitconfig_path)
+ if not os.path.exists(kunit_kernel.kunitconfig_path):
+ create_default_kunitconfig()
+
if not linux:
linux = kunit_kernel.LinuxSourceTree()
request = KunitConfigRequest(cli_args.build_dir,
- cli_args.defconfig,
cli_args.make_options)
result = config_tests(linux, request)
kunit_parser.print_with_timestamp((
@@ -284,6 +287,9 @@ def main(argv, linux=None):
cli_args.build_dir,
kunit_kernel.kunitconfig_path)
+ if not os.path.exists(kunit_kernel.kunitconfig_path):
+ create_default_kunitconfig()
+
if not linux:
linux = kunit_kernel.LinuxSourceTree()
@@ -305,6 +311,9 @@ def main(argv, linux=None):
cli_args.build_dir,
kunit_kernel.kunitconfig_path)
+ if not os.path.exists(kunit_kernel.kunitconfig_path):
+ create_default_kunitconfig()
+
if not linux:
linux = kunit_kernel.LinuxSourceTree()
--
2.26.2
Hi,
This patchset will try to enable as many KUnit test fragments as
possible for the current .config file.
This will make it easier for both developers that tests their specific
feature and also for test-systems that would like to get as much as
possible for their current .config file.
I will send a separate KCSAN KUnit patch after this patchset since that
isn't in mainline yet.
Since v2:
Fixed David's comments. KUNIT_RUN_ALL -> KUNIT_ALL_TESTS, and he
suggested a great help text.
Since v1:
Marco commented to split up the patches, and change a "." to a ",".
Cheers,
Anders
Anders Roxell (6):
kunit: Kconfig: enable a KUNIT_ALL_TESTS fragment
kunit: default KUNIT_* fragments to KUNIT_ALL_TESTS
lib: Kconfig.debug: default KUNIT_* fragments to KUNIT_ALL_TESTS
drivers: base: default KUNIT_* fragments to KUNIT_ALL_TESTS
fs: ext4: default KUNIT_* fragments to KUNIT_ALL_TESTS
security: apparmor: default KUNIT_* fragments to KUNIT_ALL_TESTS
drivers/base/Kconfig | 3 ++-
drivers/base/test/Kconfig | 3 ++-
fs/ext4/Kconfig | 3 ++-
lib/Kconfig.debug | 6 ++++--
lib/kunit/Kconfig | 23 ++++++++++++++++++++---
security/apparmor/Kconfig | 3 ++-
6 files changed, 32 insertions(+), 9 deletions(-)
--
2.20.1
Add an FAQ entry to the KUnit documentation with some tips for
troubleshooting KUnit and kunit_tool.
These suggestions largely came from an email thread:
https://lore.kernel.org/linux-kselftest/41db8bbd-3ba0-8bde-7352-083bf4b947f…
Signed-off-by: David Gow <davidgow(a)google.com>
---
Documentation/dev-tools/kunit/faq.rst | 32 +++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/Documentation/dev-tools/kunit/faq.rst b/Documentation/dev-tools/kunit/faq.rst
index ea55b2467653..40109d425988 100644
--- a/Documentation/dev-tools/kunit/faq.rst
+++ b/Documentation/dev-tools/kunit/faq.rst
@@ -61,3 +61,35 @@ test, or an end-to-end test.
kernel by installing a production configuration of the kernel on production
hardware with a production userspace and then trying to exercise some behavior
that depends on interactions between the hardware, the kernel, and userspace.
+
+KUnit isn't working, what should I do?
+======================================
+
+Unfortunately, there are a number of things which can break, but here are some
+things to try.
+
+1. Try running ``./tools/testing/kunit/kunit.py run`` with the ``--raw_output``
+ parameter. This might show details or error messages hidden by the kunit_tool
+ parser.
+2. Instead of running ``kunit.py run``, try running ``kunit.py config``,
+ ``kunit.py build``, and ``kunit.py exec`` independently. This can help track
+ down where an issue is occurring. (If you think the parser is at fault, you
+ can run it manually against stdin or a file with ``kunit.py parse``.)
+3. Running the UML kernel directly can often reveal issues or error messages
+ kunit_tool ignores. This should be as simple as running ``./vmlinux`` after
+ building the UML kernel (e.g., by using ``kunit.py build``). Note that UML
+ has some unusual requirements (such as the host having a tmpfs filesystem
+ mounted), and has had issues in the past when built statically and the host
+ has KASLR enabled. (On older host kernels, you may need to run ``setarch
+ `uname -m` -R ./vmlinux`` to disable KASLR.)
+4. Make sure the kernel .config has ``CONFIG_KUNIT=y`` and at least one test
+ (e.g. ``CONFIG_KUNIT_EXAMPLE_TEST=y``). kunit_tool will keep its .config
+ around, so you can see what config was used after running ``kunit.py run``.
+ It also preserves any config changes you might make, so you can
+ enable/disable things with ``make ARCH=um menuconfig`` or similar, and then
+ re-run kunit_tool.
+5. Finally, running ``make ARCH=um defconfig`` before running ``kunit.py run``
+ may help clean up any residual config items which could be causing problems.
+
+If none of the above tricks help, you are always welcome to email any issues to
+kunit-dev(a)googlegroups.com.
--
2.27.0.rc2.251.g90737beb825-goog
When running with conntrack rules, the dropped overlap fragments may cause
EPERM to be returned to sendto. Instead of completely failing, just ignore
those errors and continue. If this causes packets with overlap fragments to
be dropped as expected, that is okay. And if it causes packets that are
expected to be received to be dropped, which should not happen, it will be
detected as failure.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo(a)canonical.com>
---
tools/testing/selftests/net/ip_defrag.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/net/ip_defrag.c b/tools/testing/selftests/net/ip_defrag.c
index b53fb67f8e5e..62ee927bacae 100644
--- a/tools/testing/selftests/net/ip_defrag.c
+++ b/tools/testing/selftests/net/ip_defrag.c
@@ -192,9 +192,9 @@ static void send_fragment(int fd_raw, struct sockaddr *addr, socklen_t alen,
}
res = sendto(fd_raw, ip_frame, frag_len, 0, addr, alen);
- if (res < 0)
+ if (res < 0 && errno != EPERM)
error(1, errno, "send_fragment");
- if (res != frag_len)
+ if (res >= 0 && res != frag_len)
error(1, 0, "send_fragment: %d vs %d", res, frag_len);
frag_counter++;
@@ -313,9 +313,9 @@ static void send_udp_frags(int fd_raw, struct sockaddr *addr,
iphdr->ip_len = htons(frag_len);
}
res = sendto(fd_raw, ip_frame, frag_len, 0, addr, alen);
- if (res < 0)
+ if (res < 0 && errno != EPERM)
error(1, errno, "sendto overlap: %d", frag_len);
- if (res != frag_len)
+ if (res >= 0 && res != frag_len)
error(1, 0, "sendto overlap: %d vs %d", (int)res, frag_len);
frag_counter++;
}
--
2.25.1
Hi,
Recently, I found some tests were always skipped.
Here is a series of patches to fix those issues.
The prime_numbers test is skipped in some cases because
prime_numbers.ko is not always compiled.
Since the CONFIG_PRIME_NUMBERS is not independently
configurable item (it has no title and help), it is enabled
only if other configs (DRM_DEBUG_SELFTEST etc.) select it.
To fix this issue, I added a title and help for
CONFIG_PRIME_NUMBERS.
The sysctl test is skipped because
- selftests/sysctl/config requires CONFIG_TEST_SYSCTL=y. But
since lib/test_sysctl.c doesn't use module_init(), the
test_syscall is not listed under /sys/module/ and the
test script gives up.
- Even if we make CONFIG_TEST_SYSCTL=m, the test script checks
/sys/modules/test_sysctl before loading module and gives up.
- Ayway, since the test module introduces useless sysctl
interface to the kernel, it would better be a module.
This series includes fixes for above 3 points.
- Fix lib/test_sysctl.c to use module_init()
- Fix tools/testing/selftests/sysctl/sysctl.sh to try to load
test module if it is not loaded (nor embedded).
- Fix tools/testing/selftests/sysctl/config to require
CONFIG_TEST_SYSCTL=m, not y.
Thank you,
---
Masami Hiramatsu (4):
lib: Make prime number generator independently selectable
lib: Make test_sysctl initialized as module
selftests/sysctl: Fix to load test_sysctl module
selftests/sysctl: Make sysctl test driver as a module
lib/math/Kconfig | 7 ++++++-
lib/test_sysctl.c | 2 +-
tools/testing/selftests/sysctl/config | 2 +-
tools/testing/selftests/sysctl/sysctl.sh | 13 ++-----------
4 files changed, 10 insertions(+), 14 deletions(-)
--
Masami Hiramatsu (Linaro) <mhiramat(a)kernel.org>
The test-klp-callbacks change implement a synchronization replacement of
initial code to use completion variables instead of delays. The
completion variable interlocks the busy module with the concurrent
loading of the target livepatch patches which works with the execution
flow instead of estimated time delays.
The test-klp-shadow-vars changes first refactors the code to be more of
a readable example as well as continuing to verify the component code.
The patch is broken in two to display the renaming and restructuring in
part 1 and the addition and change of logic in part 2. The last change
frees memory before bailing in case of errors.
Patchset to be merged via the livepatching tree is against: livepatching/for-next
Joe Lawrence (1):
selftests/livepatch: rework test-klp-callbacks to use completion
variables
Yannick Cote (3):
selftests/livepatch: rework test-klp-shadow-vars
selftests/livepatch: more verification in test-klp-shadow-vars
selftests/livepatch: fix mem leaks in test-klp-shadow-vars
lib/livepatch/test_klp_callbacks_busy.c | 42 +++-
lib/livepatch/test_klp_shadow_vars.c | 222 +++++++++---------
.../selftests/livepatch/test-callbacks.sh | 29 ++-
.../selftests/livepatch/test-shadow-vars.sh | 85 ++++---
4 files changed, 214 insertions(+), 164 deletions(-)
--
2.25.4
Hi,
Here is a series for adding "requires:" list for simplifying and
unifying requirement checks for each test case.
This series also includes the description line fix and
unresolved -> unsupported change ([1/7] and [2/7]).
Currently, we have many similar requirement checker to find
unconfigured or unsupported (in older kernels) feature in
each test case. I think it is a good time to unify those similar
checks.
As same as "description:" or "flags:" line, this series introduces
new "requires:" line, and convert current checking code intor the
"requires:" line.
This requires line gives some good effects, not only simplyfies
the code, but also unifies the reason message, and because it checks
the requirements before running the testc ase, it skips unneeded
ftrace initialization.
The requires line supports following checks
- tracefs interface check: Check whether the given file or directory
in the tracefs. (No suffix) [3/7],[4/7],[5/7]
- available tracer check: Check whether the given tracer is available
(":tracer" suffix) [6/7]
- README feature check: Check whether the given string is in the
README (":README" suffix) [7/7]
Note that since the requires line returns UNSUPPORTED error,
the requirements must be one of ftrace feature, but not the
user-space environmental requirement. If there is some issue
in user-space (e.g. lack of the command, modules, etc) it must
report UNRESOLVED error.
Since this series depends on following 2 commits,
commit 619ee76f5c9f ("selftests/ftrace: Return unsupported if no
error_log file") on Shuah's Kselftest tree
commit bea24f766efc ("selftests/ftrace: Distinguish between hist
and synthetic event checks") on Steven's Tracing tree
This can be applied on the tree which merged both of them.
Also, you can get the series from the following.
git://git.kernel.org/pub/scm/linux/kernel/git/mhiramat/linux.git ftracetest-requires-v1
Thank you,
---
Masami Hiramatsu (7):
selftests/ftrace: Allow ":" in description
selftests/ftrace: Return unsupported for the unconfigured features
selftests/ftrace: Add "requires:" list support
selftests/ftrace: Convert required interface checks into requires list
selftests/ftrace: Convert check_filter_file() with requires list
selftests/ftrace: Support ":tracer" suffix for requires
selftests/ftrace: Support ":README" suffix for requires
tools/testing/selftests/ftrace/ftracetest | 11 ++++++-
.../selftests/ftrace/test.d/00basic/snapshot.tc | 3 +-
.../selftests/ftrace/test.d/00basic/trace_pipe.tc | 3 +-
.../ftrace/test.d/direct/kprobe-direct.tc | 6 +---
.../ftrace/test.d/dynevent/add_remove_kprobe.tc | 6 +---
.../ftrace/test.d/dynevent/add_remove_synth.tc | 5 +--
.../ftrace/test.d/dynevent/clear_select_events.tc | 11 +------
.../ftrace/test.d/dynevent/generic_clear_event.tc | 8 +----
.../selftests/ftrace/test.d/event/event-enable.tc | 6 +---
.../selftests/ftrace/test.d/event/event-no-pid.tc | 11 +------
.../selftests/ftrace/test.d/event/event-pid.tc | 11 +------
.../ftrace/test.d/event/subsystem-enable.tc | 6 +---
.../ftrace/test.d/event/toplevel-enable.tc | 6 +---
.../ftrace/test.d/ftrace/fgraph-filter-stack.tc | 14 +--------
.../ftrace/test.d/ftrace/fgraph-filter.tc | 8 +----
.../ftrace/test.d/ftrace/func-filter-glob.tc | 8 +----
.../test.d/ftrace/func-filter-notrace-pid.tc | 13 +-------
.../ftrace/test.d/ftrace/func-filter-pid.tc | 13 +-------
.../ftrace/test.d/ftrace/func-filter-stacktrace.tc | 3 +-
.../selftests/ftrace/test.d/ftrace/func_cpumask.tc | 6 +---
.../ftrace/test.d/ftrace/func_event_triggers.tc | 7 ++---
.../ftrace/test.d/ftrace/func_mod_trace.tc | 3 +-
.../ftrace/test.d/ftrace/func_profile_stat.tc | 3 +-
.../ftrace/test.d/ftrace/func_profiler.tc | 12 +-------
.../ftrace/test.d/ftrace/func_set_ftrace_file.tc | 6 ++--
.../ftrace/test.d/ftrace/func_stack_tracer.tc | 8 +----
.../test.d/ftrace/func_traceonoff_triggers.tc | 6 ++--
.../ftrace/test.d/ftrace/tracing-error-log.tc | 12 ++------
tools/testing/selftests/ftrace/test.d/functions | 28 ++++++++++++++----
.../ftrace/test.d/instances/instance-event.tc | 6 +---
.../selftests/ftrace/test.d/instances/instance.tc | 6 +---
.../ftrace/test.d/kprobe/add_and_remove.tc | 3 +-
.../selftests/ftrace/test.d/kprobe/busy_check.tc | 3 +-
.../selftests/ftrace/test.d/kprobe/kprobe_args.tc | 3 +-
.../ftrace/test.d/kprobe/kprobe_args_comm.tc | 3 +-
.../ftrace/test.d/kprobe/kprobe_args_string.tc | 3 +-
.../ftrace/test.d/kprobe/kprobe_args_symbol.tc | 3 +-
.../ftrace/test.d/kprobe/kprobe_args_syntax.tc | 5 +--
.../ftrace/test.d/kprobe/kprobe_args_type.tc | 5 +--
.../ftrace/test.d/kprobe/kprobe_args_user.tc | 5 +--
.../ftrace/test.d/kprobe/kprobe_eventname.tc | 3 +-
.../ftrace/test.d/kprobe/kprobe_ftrace.tc | 6 +---
.../ftrace/test.d/kprobe/kprobe_module.tc | 3 +-
.../ftrace/test.d/kprobe/kprobe_multiprobe.tc | 5 +--
.../ftrace/test.d/kprobe/kprobe_syntax_errors.tc | 5 +--
.../ftrace/test.d/kprobe/kretprobe_args.tc | 3 +-
.../ftrace/test.d/kprobe/kretprobe_maxactive.tc | 4 +--
.../ftrace/test.d/kprobe/multiple_kprobes.tc | 3 +-
.../selftests/ftrace/test.d/kprobe/probepoint.tc | 3 +-
.../selftests/ftrace/test.d/kprobe/profile.tc | 3 +-
.../ftrace/test.d/kprobe/uprobe_syntax_errors.tc | 5 +--
.../ftrace/test.d/preemptirq/irqsoff_tracer.tc | 4 +--
tools/testing/selftests/ftrace/test.d/template | 4 +++
.../selftests/ftrace/test.d/tracer/wakeup.tc | 6 +---
.../selftests/ftrace/test.d/tracer/wakeup_rt.tc | 6 +---
.../inter-event/trigger-action-hist-xfail.tc | 13 +-------
.../inter-event/trigger-field-variable-support.tc | 16 +---------
.../trigger-inter-event-combined-hist.tc | 16 +---------
.../inter-event/trigger-multi-actions-accept.tc | 16 +---------
.../inter-event/trigger-onchange-action-hist.tc | 8 +----
.../inter-event/trigger-onmatch-action-hist.tc | 16 +---------
.../trigger-onmatch-onmax-action-hist.tc | 16 +---------
.../inter-event/trigger-onmax-action-hist.tc | 16 +---------
.../inter-event/trigger-snapshot-action-hist.tc | 20 +------------
.../trigger-synthetic-event-createremove.tc | 11 +------
.../inter-event/trigger-synthetic-event-syntax.tc | 11 +------
.../inter-event/trigger-trace-action-hist.tc | 18 +-----------
.../ftrace/test.d/trigger/trigger-eventonoff.tc | 11 +------
.../ftrace/test.d/trigger/trigger-filter.tc | 11 +------
.../ftrace/test.d/trigger/trigger-hist-mod.tc | 16 +---------
.../test.d/trigger/trigger-hist-syntax-errors.tc | 18 +-----------
.../ftrace/test.d/trigger/trigger-hist.tc | 16 +---------
.../ftrace/test.d/trigger/trigger-multihist.tc | 16 +---------
.../ftrace/test.d/trigger/trigger-snapshot.tc | 16 +---------
.../ftrace/test.d/trigger/trigger-stacktrace.tc | 11 +------
.../test.d/trigger/trigger-trace-marker-hist.tc | 21 +-------------
.../trigger/trigger-trace-marker-snapshot.tc | 21 +-------------
.../trigger-trace-marker-synthetic-kernel.tc | 31 +-------------------
.../trigger/trigger-trace-marker-synthetic.tc | 26 +----------------
.../ftrace/test.d/trigger/trigger-traceonoff.tc | 11 +------
80 files changed, 120 insertions(+), 633 deletions(-)
--
Masami Hiramatsu (Linaro) <mhiramat(a)kernel.org>
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 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/seccomp/settings b/tools/testing/selftests/seccomp/settings
index d61f00d8cad3..ba4d85f74cd6 100644
--- a/tools/testing/selftests/seccomp/settings
+++ b/tools/testing/selftests/seccomp/settings
@@ -1 +1 @@
-90
+timeout=90
--
2.25.1
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
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
On Tue, 26 May 2020, Emanuele Giuseppe Esposito wrote:
> Add kunit tests to extensively test the stats_fs API functionality.
>
I've added in the kunit-related folks.
> In order to run them, the kernel .config must set CONFIG_KUNIT=y
> and a new .kunitconfig file must be created with CONFIG_STATS_FS=y
> and CONFIG_STATS_FS_TEST=y
>
It looks like CONFIG_STATS_FS is built-in, but it exports
much of the functionality you are testing. However could the
tests also be built as a module (i.e. make CONFIG_STATS_FS_TEST
a tristate variable)? To test this you'd need to specify
CONFIG_KUNIT=m and CONFIG_STATS_FS_TEST=m, and testing would
simply be a case of "modprobe"ing the stats fs module and collecting
results in /sys/kernel/debug/kunit/<module_name> (rather
than running kunit.py). Are you relying on unexported internals in
the the tests that would prevent building them as a module?
Thanks!
Alan
Hi, Andrii!
>>>>> On Tue, 26 May 2020 15:32:10 -0700, Andrii Nakryiko wrote:
> On Thu, May 21, 2020 at 11:41 PM Yauheni Kaliuta
> <yauheni.kaliuta(a)redhat.com> wrote:
>>
>>
>> Actually, a bit more needed :)
> From the other kselftest thread, it seems like selftests are not
> supporting builds out-of-tree. With that, wouldn't it be simpler to
> build in tree and then just copy selftests/bpf directory to wherever
> you need to run tests from? It would be simple and reliable. Given I
> and probably everyone else never build and run tests out-of-tree, it's
> just too easy to break this and you'll be constantly chasing some
> non-obvious breakages...
> Is there some problem with such approach?
This is `make install` ;).
I personally do not need OOT build, but since it's in the code,
I'd prefer either fix it or remove it, otherwise it's
misleading. But I have not got reply from kselftest.
>>
>> >>>>> On Fri, 22 May 2020 07:13:02 +0300, Yauheni Kaliuta wrote:
>>
>> > I had a look, here are some fixes.
>> > Yauheni Kaliuta (8):
>> > selftests/bpf: remove test_align from Makefile
>> > selftests/bpf: build bench.o for any $(OUTPUT)
>> > selftests/bpf: install btf .c files
>> > selftests/bpf: fix object files installation
>> > selftests/bpf: add output dir to include list
>> > selftests/bpf: fix urandom_read installation
>> > selftests/bpf: fix test.h placing for out of tree build
>> > selftests/bpf: factor out MKDIR rule
>>
>> > tools/testing/selftests/bpf/Makefile | 77 ++++++++++++++++++++--------
>> > 1 file changed, 55 insertions(+), 22 deletions(-)
>>
>> > --
>> > 2.26.2
>>
>>
>> --
>> WBR,
>> Yauheni Kaliuta
>>
--
WBR,
Yauheni Kaliuta
Hi, all.
I met a strange problem that kunit run 0 tests in Debian9.
Env:
```
root@lkp-hsw-ep4 ~/linus# head /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
root@lkp-hsw-ep4 ~/linus# uname -r
5.6.0
```
Reproduce: Just run `./tools/testing/kunit/kunit.py run --defconfig`
```
root@lkp-hsw-ep4 ~/linus# ./tools/testing/kunit/kunit.py run --defconfig
[13:41:30] Building KUnit Kernel ...
[13:41:33] Starting KUnit Kernel ...
[13:41:33] ============================================================
[13:41:33] Testing complete. 0 tests run. 0 failed. 0 crashed.
[13:41:33] Elapsed time: 2.619s total, 0.002s configuring, 2.610s
building, 0.007s running
root@lkp-hsw-ep4 ~/linus# cat .kunitconfig
CONFIG_KUNIT=y
CONFIG_KUNIT_TEST=y
CONFIG_KUNIT_EXAMPLE_TEST=y
```
As doc said, looks like everything worked correctly. But kunit run 0 tests.
```
If everything worked correctly, you should see the following:
Generating .config ...
Building KUnit Kernel ...
Starting KUnit Kernel ...
```
--
Best regards.
Liu Yiding
To make KUnit easier to use, and to avoid overwriting object and
.config files, the default KUnit build directory is set to .kunit
* Related bug: https://bugzilla.kernel.org/show_bug.cgi?id=205221
Fixed up minor merge conflicts - Shuah Khan <skhan(a)linuxfoundation.org>
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>
---
version after merge on kunit brach:
* fix identation (tabs instead of spaces)
---
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
On 5/19/20 8:49 AM, Yauheni Kaliuta wrote:
> Hi, shuah!
>
>>>>>> On Tue, 19 May 2020 07:59:16 -0600, shuah wrote:
>
> > On 5/15/20 6:00 AM, Yauheni Kaliuta wrote:
> >>
> >> Yauheni Kaliuta (3):
> >> selftests: do not use .ONESHELL
> >> selftests: fix condition in run_tests
> >> selftests: simplify run_tests
> >>
> >> tools/testing/selftests/lib.mk | 19 ++++++-------------
> >> 1 file changed, 6 insertions(+), 13 deletions(-)
> >>
>
> > Quick note that, I will pull these in for 5.8-rc1.
Patches look okay to me, however, just noticed, this series hasn't
been cc'ed to linux-kselftest. Hence it didn't go through the
necessary reviews.
Please run get_maintainers and resend the series to everybody the
script suggests.
thanks,
-- Shuah
Hi!
lib.mk expects TEST_GEN_PROGS, TEST_GEN_PROGS_EXTENDED and
TEST_GEN_FILES to be in local directory and tries to handle out
of tree build adding OUTPUT to it at the beginning.
commit be16a244c199 ("selftests: lib.mk: add TEST_CUSTOM_PROGS to
allow custom test run/install") adds TEST_CUSTOM_PROGS but it
handles it differently. Should it add OUTPUT as well?
--
WBR,
Yauheni Kaliuta
I hope you are doing great?
This is Felix from Toronto-Canada. I have a lucrative business
offer that will benefit us both immensely within a very short
period of time. However, I need your initial approval of interest
prior to further and complete details regarding the deal.
Thanks,
Felix.