In some platform, the schedule event may came slowly, delay 100ms can't
cover it.
I was notice that on my board which running in low cpu_freq,and this
selftests allways gose fail.
So maybe we can check more times here to wait longer.
Fixes: 43bb45da82f9 ("selftests: ftrace: Add a selftest to test event enable/disable func trigger")
Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com>
---
.../ftrace/test.d/ftrace/func_event_triggers.tc | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc b/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc
index 8d26d5505808..3eea2abf68f9 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc
@@ -38,11 +38,18 @@ cnt_trace() {
test_event_enabled() {
val=$1
+ check_times=10 # wait for 10 * SLEEP_TIME at most
- e=`cat $EVENT_ENABLE`
- if [ "$e" != $val ]; then
- fail "Expected $val but found $e"
- fi
+ while [ $check_times -ne 0 ]; do
+ e=`cat $EVENT_ENABLE`
+ if [ "$e" == $val ]; then
+ return 0
+ fi
+ sleep $SLEEP_TIME
+ check_times=$((check_times - 1))
+ done
+
+ fail "Expected $val but found $e"
}
run_enable_disable() {
--
2.17.1
Hi,
I'm facing a couple of issues when testing KUnit with the i915 driver.
The DRM subsystem and the i915 driver has, for a long time, his own
way to do unit tests, which seems to be added before KUnit.
I'm now checking if it is worth start using KUnit at i915. So, I wrote
a RFC with some patches adding support for the tests we have to be
reported using Kernel TAP and KUnit.
There are basically 3 groups of tests there:
- mock tests - check i915 hardware-independent logic;
- live tests - run some hardware-specific tests;
- perf tests - check perf support - also hardware-dependent.
As they depend on i915 driver, they run only on x86, with PCI
stack enabled, but the mock tests run nicely via qemu.
The live and perf tests require a real hardware. As we run them
together with our CI, which, among other things, test module
unload/reload and test loading i915 driver with different
modprobe parameters, the KUnit tests should be able to run as
a module.
While testing KUnit, I noticed a couple of issues:
1. kunit.py parser is currently broken when used with modules
the parser expects "TAP version xx" output, but this won't
happen when loading the kunit test driver.
Are there any plans or patches fixing this issue?
2. current->mm is not initialized
Some tests do mmap(). They need the mm user context to be initialized,
but this is not happening right now.
Are there a way to properly initialize it for KUnit?
3. there's no test filters for modules
In order to be able to do proper CI automation, it is needed to
be able to control what tests will run or not. That's specially
interesting at development time where some tests may not apply
or not run properly on new hardware.
Are there any plans to add support for it at kunit_test_suites()
when the driver is built as module? Ideally, the best would be to
export a per-module filter_glob parameter on such cases.
4. there are actually 3 levels of tests on i915:
- Level 1: mock, live, perf
- Level 2: test group (mmap, fences, ...)
- Level 3: unit tests
Currently, KUnit seems to have just two levels (test suite and tests).
Are there a way to add test groups there?
Regards,
Mauro
Forwarded message:
Date: Thu, 3 Nov 2022 14:51:38 +0000
From: Mauro Carvalho Chehab <mchehab(a)kernel.org>
To:
Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com>, linux-kselftest(a)vger.kernel.org, Michał Winiarski <michal.winiarski(a)intel.com>, dri-devel(a)lists.freedesktop.org, intel-gfx(a)lists.freedesktop.org, Daniel Latypov <dlatypov(a)google.com>, linux-kernel(a)vger.kernel.org, igt-dev(a)lists.freedesktop.org, Matthew Auld <matthew.auld(a)intel.com>, Daniel Vetter <daniel(a)ffwll.ch>, Rodrigo Vivi <rodrigo.vivi(a)intel.com>, skhan(a)linuxfoundation.org, Isabella Basso <isabbasso(a)riseup.net>, David Airlie <airlied(a)gmail.com>, Christian König <christian.koenig(a)amd.com>
Subject: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL
The mmap tests require mm in order to work. Failing to do that
will cause a crash:
[ 316.820722] BUG: kernel NULL pointer dereference, address: 00000000000000e8
[ 316.822517] #PF: supervisor write access in kernel mode
[ 316.823430] #PF: error_code(0x0002) - not-present page
[ 316.824390] PGD 0 P4D 0
[ 316.825357] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ 316.826350] CPU: 0 PID: 1517 Comm: kunit_try_catch Tainted: G U N 6.1.0-rc2-drm-266703e6f163+ #14
[ 316.827503] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake Y LPDDR4x T4 Crb, BIOS TGLSFWI1.R00.3243.A01.2006102133 06/10/2020
[ 316.828633] RIP: 0010:down_write_killable+0x50/0x110
[ 316.829756] Code: 24 10 45 31 c9 31 c9 41 b8 01 00 00 00 31 d2 31 f6 48 89 ef e8 e1 74 4a ff bf 01 00 00 00 e8 87 d6 46 ff 31 c0 ba 01 00 00 00 <f0> 48 0f b1 13 0f 94 c0 5a 84 c0 74 62 8b 05 49 12 e4 00 85 c0 74
[ 316.830896] RSP: 0018:ffffc90001eabc58 EFLAGS: 00010246
[ 316.832008] RAX: 0000000000000000 RBX: 00000000000000e8 RCX: 0000000000000000
[ 316.833141] RDX: 0000000000000001 RSI: ffffffff81c94fc9 RDI: ffffffff81c94fc9
[ 316.834195] RBP: 0000000000000158 R08: 0000000000000001 R09: 0000000000000000
[ 316.835231] R10: 0000000000000000 R11: ffff8883a13350b8 R12: 0000000000000002
[ 316.836259] R13: 0000000000000001 R14: 0000000000100000 R15: 00000000000000e8
[ 316.837237] FS: 0000000000000000(0000) GS:ffff8883a3800000(0000) knlGS:0000000000000000
[ 316.838214] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 316.839190] CR2: 00000000000000e8 CR3: 0000000002812003 CR4: 0000000000770ef0
[ 316.840147] PKRU: 55555554
[ 316.841099] Call Trace:
[ 316.842047] <TASK>
[ 316.842990] ? vm_mmap_pgoff+0x78/0x150
[ 316.843936] vm_mmap_pgoff+0x78/0x150
[ 316.844884] igt_mmap_offset+0x178/0x1b9 [i915]
[ 316.846119] __igt_mmap+0xfe/0x680 [i915]
Unfortunately, when KUnit module runs, it doesn't create an
user context, causing mmap tests to fail.
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org>
---
To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover.
See [PATCH RFC v2 0/8] at: https://lore.kernel.org/all/cover.1667486144.git.mchehab@kernel.org/
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index add5ae56cd89..2c5f93e946b5 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -1845,6 +1845,11 @@ int i915_gem_mman_live_selftests(struct drm_i915_private *i915)
SUBTEST(igt_mmap_gpu),
};
+ if (!current->mm) {
+ pr_err("Test called without an user context!\n");
+ return -EINVAL;
+ }
+
return i915_live_subtests(tests, i915);
}
EXPORT_SYMBOL_NS_GPL(i915_gem_mman_live_selftests, I915_SELFTEST);
--
2.38.1
Hi,
This is v2 of the fix & selftest previously sent at:
https://lore.kernel.org/linux-mm/20221108195211.214025-1-flaniel@linux.micr…
Changes v1 to v2:
- add 'cc:stable', 'Fixes:' and review/ack tags
- update commitmsg and fix my email
- rebase on bpf tree and tag for bpf tree
Thanks!
Alban Crequy (2):
maccess: fix writing offset in case of fault in
strncpy_from_kernel_nofault()
selftests: bpf: add a test when bpf_probe_read_kernel_str() returns
EFAULT
mm/maccess.c | 2 +-
tools/testing/selftests/bpf/prog_tests/varlen.c | 7 +++++++
tools/testing/selftests/bpf/progs/test_varlen.c | 5 +++++
3 files changed, 13 insertions(+), 1 deletion(-)
--
2.36.1
The proses written in KUnit documentation are IMO incomprehensible (my
brain has to process what the meaning of words used) and different from
wordings that I normally read from technical writings. Thus, rewrite these
using clearer words.
Anyway, it's great to see native English speakers help reviewing this
series.
The first two patches are v3 of rewriting "Writing Your First Test"
section of "Getting Started" patch [1], which was submitted about a
month ago. The rest are actual documentation rewriting.
Note that this series only rewrites intro, test writing and running docs.
[1]: https://lore.kernel.org/lkml/20220929132549.56452-1-bagasdotme@gmail.com/
Bagas Sanjaya (7):
Documentation: kunit: rewrite "Writing Your First Test" section
Documentation: kunit: align instruction code blocks
Documentation: kunit: rewrite the rest of "Getting Started"
documentation
Documentation: kunit: move introduction to its own document
Documentation: kunit: rewrite "Running tests with kunit_tool"
Documentation: kunit: rewrite "Run Tests without kunit_tool"
Documentation: kunit: rewrite "Writing tests"
Documentation/admin-guide/README.rst | 2 +
Documentation/dev-tools/kunit/index.rst | 93 +----
Documentation/dev-tools/kunit/intro.rst | 61 ++++
Documentation/dev-tools/kunit/run_manual.rst | 68 ++--
Documentation/dev-tools/kunit/run_wrapper.rst | 302 ++++++----------
Documentation/dev-tools/kunit/start.rst | 264 +++++++-------
Documentation/dev-tools/kunit/usage.rst | 322 ++++++++++--------
7 files changed, 483 insertions(+), 629 deletions(-)
create mode 100644 Documentation/dev-tools/kunit/intro.rst
base-commit: de3ee3f63400a23954e7c1ad1cb8c20f29ab6fe3
--
An old man doll... just what I always wanted! - Clara
Hello Linus,
I've been trying since July to get this regression that was introduced in
5.14 fixed. This is my third time submitting this version of the patch in the
last two months. Both prior submissions have not received any comments from
(nor have they been applied by) the x86 maintainers. I don't really know
what else to do at this point beyond "complain to the management" as it
were.
I appreciate anything you can do to unjam things here.
- Kyle
Arm have recently released versions 2 and 2.1 of the SME extension.
Among the features introduced by SME 2 is some new architectural state,
the ZT0 register. This series adds support for this and all the other
features of the new SME versions.
Since the architecture has been designed with the possibility of adding
further ZTn registers in mind the interfaces added for ZT0 are done with
this possibility in mind. As ZT0 is a simple fixed size register these
interfaces are all fairly simple, the main complication is that ZT0 is
only accessible when PSTATE.ZA is enabled. The memory allocation that we
already do for PSTATE.ZA is extended to include space for ZT0.
Due to textual collisions especially around the addition of hwcaps this
is based on the concurrently sent series "arm64: Support for 2022 data
processing instructions" but there is no meaningful interaction.
v2:
- Add missing initialisation of user->zt in signal context parsing.
- Change the magic for ZT signal frames to 0x5a544e01 (ZTN0).
Mark Brown (21):
arm64/sme: Rename za_state to sme_state
arm64: Document boot requirements for SME 2
arm64/sysreg: Update system registers for SME 2 and 2.1
arm64/sme: Document SME 2 and SME 2.1 ABI
arm64/esr: Document ISS for ZT0 being disabled
arm64/sme: Manually encode ZT0 load and store instructions
arm64/sme: Enable host kernel to access ZT0
arm64/sme: Add basic enumeration for SME2
arm64/sme: Provide storage for ZT0
arm64/sme: Implement context switching for ZT0
arm64/sme: Implement signal handling for ZT
arm64/sme: Implement ZT0 ptrace support
arm64/sme: Add hwcaps for SME 2 and 2.1 features
kselftest/arm64: Add a stress test program for ZT0
kselftest/arm64: Cover ZT in the FP stress test
kselftest/arm64: Enumerate SME2 in the signal test utility code
kselftest/arm64: Teach the generic signal context validation about ZT
kselftest/arm64: Add test coverage for ZT register signal frames
kselftest/arm64: Add SME2 coverage to syscall-abi
kselftest/arm64: Add coverage of the ZT ptrace regset
kselftest/arm64: Add coverage of SME 2 and 2.1 hwcaps
Documentation/arm64/booting.rst | 10 +
Documentation/arm64/elf_hwcaps.rst | 18 +
Documentation/arm64/sme.rst | 52 ++-
arch/arm64/include/asm/cpufeature.h | 6 +
arch/arm64/include/asm/esr.h | 1 +
arch/arm64/include/asm/fpsimd.h | 28 +-
arch/arm64/include/asm/fpsimdmacros.h | 22 ++
arch/arm64/include/asm/hwcap.h | 6 +
arch/arm64/include/asm/processor.h | 2 +-
arch/arm64/include/uapi/asm/hwcap.h | 6 +
arch/arm64/include/uapi/asm/sigcontext.h | 19 +
arch/arm64/kernel/cpufeature.c | 27 ++
arch/arm64/kernel/cpuinfo.c | 6 +
arch/arm64/kernel/entry-fpsimd.S | 30 +-
arch/arm64/kernel/fpsimd.c | 53 ++-
arch/arm64/kernel/hyp-stub.S | 6 +
arch/arm64/kernel/idreg-override.c | 1 +
arch/arm64/kernel/process.c | 21 +-
arch/arm64/kernel/ptrace.c | 60 ++-
arch/arm64/kernel/signal.c | 113 +++++-
arch/arm64/tools/cpucaps | 1 +
arch/arm64/tools/sysreg | 26 +-
include/uapi/linux/elf.h | 1 +
tools/testing/selftests/arm64/abi/hwcap.c | 115 ++++++
.../selftests/arm64/abi/syscall-abi-asm.S | 43 ++-
.../testing/selftests/arm64/abi/syscall-abi.c | 40 +-
tools/testing/selftests/arm64/fp/.gitignore | 2 +
tools/testing/selftests/arm64/fp/Makefile | 5 +
tools/testing/selftests/arm64/fp/fp-stress.c | 29 +-
tools/testing/selftests/arm64/fp/sme-inst.h | 20 +
tools/testing/selftests/arm64/fp/zt-ptrace.c | 365 ++++++++++++++++++
tools/testing/selftests/arm64/fp/zt-test.S | 324 ++++++++++++++++
.../testing/selftests/arm64/signal/.gitignore | 1 +
.../selftests/arm64/signal/test_signals.h | 2 +
.../arm64/signal/test_signals_utils.c | 3 +
.../arm64/signal/testcases/testcases.c | 36 ++
.../arm64/signal/testcases/testcases.h | 1 +
.../arm64/signal/testcases/zt_no_regs.c | 51 +++
.../arm64/signal/testcases/zt_regs.c | 85 ++++
39 files changed, 1564 insertions(+), 73 deletions(-)
create mode 100644 tools/testing/selftests/arm64/fp/zt-ptrace.c
create mode 100644 tools/testing/selftests/arm64/fp/zt-test.S
create mode 100644 tools/testing/selftests/arm64/signal/testcases/zt_no_regs.c
create mode 100644 tools/testing/selftests/arm64/signal/testcases/zt_regs.c
base-commit: ab0aff0601c29dc7b5cb2ecf42135dccbed6750a
--
2.30.2