The buffer used for verifying SVE Z registers allocated enough space for
16 maximally sized registers rather than 32 due to using the macro for the
number of P registers. In practice this didn't matter since for historical
reasons the maximum VQ defined in the ABI is greater the architectural
maximum so we will always allocate more space than is needed even with
emulated platforms implementing the architectural maximum. Still, we should
use the right define.
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
tools/testing/selftests/arm64/abi/syscall-abi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/arm64/abi/syscall-abi.c b/tools/testing/selftests/arm64/abi/syscall-abi.c
index b632bfe9e022..95229fa73232 100644
--- a/tools/testing/selftests/arm64/abi/syscall-abi.c
+++ b/tools/testing/selftests/arm64/abi/syscall-abi.c
@@ -113,8 +113,8 @@ static int check_fpr(struct syscall_cfg *cfg, int sve_vl, int sme_vl,
}
static uint8_t z_zero[__SVE_ZREG_SIZE(SVE_VQ_MAX)];
-uint8_t z_in[SVE_NUM_PREGS * __SVE_ZREG_SIZE(SVE_VQ_MAX)];
-uint8_t z_out[SVE_NUM_PREGS * __SVE_ZREG_SIZE(SVE_VQ_MAX)];
+uint8_t z_in[SVE_NUM_ZREGS * __SVE_ZREG_SIZE(SVE_VQ_MAX)];
+uint8_t z_out[SVE_NUM_ZREGS * __SVE_ZREG_SIZE(SVE_VQ_MAX)];
static void setup_z(struct syscall_cfg *cfg, int sve_vl, int sme_vl,
uint64_t svcr)
--
2.30.2
Hi Paul,
as previously promised, here comes the nolibc update which introduces the
minimal self-test infrastructure that aims at being reasonably easy to
expand further.
It's based on your branch "dev.2022.06.30b" that contains the previous
minor fixes that aimed at addressing Linus' concerns about the build
process inconsistencies.
The way it works tries to mimmick as much as possible the regular build
process, so that it reuses the same ARCH, CC, CROSS_COMPILE to build the
test program, that will be embedded into an initramfs and the kernel is
(re)built with that initramfs. Then you can decide to run that kernel
under QEMU for the supported archs, and the output of the tests appears
in an output text file in a format that's easily greppable and diffable.
A single target "run" does everything.
By default it will reuse your existing .config (so that developers
continue to use their regular config handling), though it can also
create a known-to-work defconfig for each arch. The reason behind this
is that it took me a moment to figure certain defconfig + machine name
combinations and I found it better to put them there once for all.
I've successfully tested it on arm, arm64, i386, x86_64. riscv64 works
except two syscalls which return unexpected errors, and mips segfaults
in sbrk(). I don't know why yet, but this proves that it's worth having
such a test.
There are not that many tests yet (71), those that have to run can be
filtered either from the program's command line or from a NOLIBC_TEST
environment variable so that it's possible to skip broken ones or to
focus on a few ranges only.
Tests are numerically numbered, and are conveniently handled in a
switch/case statement so that a relative line number assigns the number
to the test. That's convenient because the vast majority of syscall tests
are one-liners. This sometimes slightly upsets check-patch when lines get
moderately long but that significantly improves legibility.
There are expectation for both successes and failures (e.g. -1 ENOTDIR).
I'm sure this can be improved later (and that's the goal). Right now it
covers two test families:
- syscalls
- stdlib (str* functions mostly)
I suspect that over time we might want to split syscalls into different
parts (e.g. core, fs, etc maybe) but I could be wrong.
The program can automatically modulate QEMU's return value on x86 when
QEMU is run with the appropriate options, but for now I'm not using it
as I felt like it didn't bring much value, and the output is more useful.
That's debatable, and maybe some might want to use it in bisect scripts
for example. It's too early to say IMHO.
Oh, I also arranged the code so that the test also builds with glibc. I
noticed that when adding a new test that fails, sometimes it's convenient
to see if it's the nolibc part that's broken or the test. I don't find
this critical but the required includes and ifdefs are there so that it
should be easy to maintain over time as well.
I'm obviously interested in comments, but really, I don't want to
overdesign something for a first step, it remains a very modest test
program and I'd like that it remains easy to hack on it and to contribute
new tests that are deemed useful.
I'm CCing the few who already contributed some patches and/or expressed
interest, as well as Linus who had a first bad experience when trying to
test it, hoping this one will be better. I'm pasting below [1] a copy of
a test on x86_64 below, that's summed up as "71 test(s) passed" at the
end of the "run" target.
If there's no objection, it would be nice to have this with your current
series, as it definitely helps spot and fix the bugs. In parallel I'll see
if I can figure the problems with the two tests that fail each on a
specific arch and I might possibly have a few extra fixes for the current
nolibc.
Thank you!
Willy
[1] example output
----8<----
Running test 'syscall'
0 getpid = 1 [OK]
1 getppid = 0 [OK]
5 getpgid_self = 0 [OK]
6 getpgid_bad = -1 ESRCH [OK]
7 kill_0 = 0 [OK]
8 kill_CONT = 0 [OK]
9 kill_BADPID = -1 ESRCH [OK]
10 sbrk = 0 [OK]
11 brk = 0 [OK]
12 chdir_root = 0 [OK]
13 chdir_dot = 0 [OK]
14 chdir_blah = -1 ENOENT [OK]
15 chmod_net = 0 [OK]
16 chmod_self = -1 EPERM [OK]
17 chown_self = -1 EPERM [OK]
18 chroot_root = 0 [OK]
19 chroot_blah = -1 ENOENT [OK]
20 chroot_exe = -1 ENOTDIR [OK]
21 close_m1 = -1 EBADF [OK]
22 close_dup = 0 [OK]
23 dup_0 = 3 [OK]
24 dup_m1 = -1 EBADF [OK]
25 dup2_0 = 100 [OK]
26 dup2_m1 = -1 EBADF [OK]
27 dup3_0 = 100 [OK]
28 dup3_m1 = -1 EBADF [OK]
29 execve_root = -1 EACCES [OK]
30 getdents64_root = 120 [OK]
31 getdents64_null = -1 ENOTDIR [OK]
32 gettimeofday_null = 0 [OK]
38 ioctl_tiocinq = 0 [OK]
39 ioctl_tiocinq = 0 [OK]
40 link_root1 = -1 EEXIST [OK]
41 link_blah = -1 ENOENT [OK]
42 link_dir = -1 EPERM [OK]
43 link_cross = -1 EXDEV [OK]
44 lseek_m1 = -1 EBADF [OK]
45 lseek_0 = -1 ESPIPE [OK]
46 mkdir_root = -1 EEXIST [OK]
47 open_tty = 3 [OK]
48 open_blah = -1 ENOENT [OK]
49 poll_null = 0 [OK]
50 poll_stdout = 1 [OK]
51 poll_fault = -1 EFAULT [OK]
52 read_badf = -1 EBADF [OK]
53 sched_yield = 0 [OK]
54 select_null = 0 [OK]
55 select_stdout = 1 [OK]
56 select_fault = -1 EFAULT [OK]
57 stat_blah = -1 ENOENT [OK]
58 stat_fault = -1 EFAULT [OK]
59 symlink_root = -1 EEXIST [OK]
60 unlink_root = -1 EISDIR [OK]
61 unlink_blah = -1 ENOENT [OK]
62 wait_child = -1 ECHILD [OK]
63 waitpid_min = -1 ESRCH [OK]
64 waitpid_child = -1 ECHILD [OK]
65 write_badf = -1 EBADF [OK]
66 write_zero = 0 [OK]
Errors during this test: 0
Running test 'stdlib'
0 getenv_TERM = <linux> [OK]
1 getenv_blah = <(null)> [OK]
2 setcmp_blah_blah = 0 [OK]
3 setcmp_blah_blah2 = -50 [OK]
4 setncmp_blah_blah = 0 [OK]
5 setncmp_blah_blah4 = 0 [OK]
6 setncmp_blah_blah5 = -53 [OK]
7 setncmp_blah_blah6 = -54 [OK]
8 strchr_foobar_o = <oobar> [OK]
9 strchr_foobar_z = <(null)> [OK]
10 strrchr_foobar_o = <obar> [OK]
11 strrchr_foobar_z = <(null)> [OK]
Errors during this test: 0
Total number of errors: 0
---->8----
--
Willy Tarreau (17):
tools/nolibc: make argc 32-bit in riscv startup code
tools/nolibc: fix build warning in sys_mmap() when my_syscall6 is not
defined
tools/nolibc: make sys_mmap() automatically use the right __NR_mmap
definition
selftests/nolibc: add basic infrastructure to ease creation of nolibc
tests
selftests/nolibc: support a test definition format
selftests/nolibc: implement a few tests for various syscalls
selftests/nolibc: add a few tests for some stdlib functions
selftests/nolibc: exit with poweroff on success when getpid() == 1
selftests/nolibc: on x86, support exiting with isa-debug-exit
selftests/nolibc: recreate and populate /dev and /proc if missing
selftests/nolibc: condition some tests on /proc existence
selftests/nolibc: support glibc as well
selftests/nolibc: add a "kernel" target to build the kernel with the
initramfs
selftests/nolibc: add a "defconfig" target
selftests/nolibc: add a "run" target to start the kernel in QEMU
selftests/nolibc: "sysroot" target installs a local copy of the
sysroot
selftests/nolibc: add a "help" target
MAINTAINERS | 1 +
tools/include/nolibc/arch-riscv.h | 2 +-
tools/include/nolibc/sys.h | 4 +-
tools/testing/selftests/nolibc/Makefile | 135 ++++
tools/testing/selftests/nolibc/nolibc-test.c | 757 +++++++++++++++++++
5 files changed, 896 insertions(+), 3 deletions(-)
create mode 100644 tools/testing/selftests/nolibc/Makefile
create mode 100644 tools/testing/selftests/nolibc/nolibc-test.c
--
2.17.5
On Tue, Jul 19, 2022 at 10:42 PM Karl MacMillan
<karl(a)bigbadwolfsecurity.com> wrote:
> On Thu, Jul 7, 2022 at 6:34 PM Frederick Lawler <fred(a)cloudflare.com> wrote:
>>
>> Unprivileged user namespace creation is an intended feature to enable
>> sandboxing, however this feature is often used to as an initial step to
>> perform a privilege escalation attack.
>>
>> This patch implements a new namespace { userns_create } access control
>> permission to restrict which domains allow or deny user namespace
>> creation. This is necessary for system administrators to quickly protect
>> their systems while waiting for vulnerability patches to be applied.
>>
>> This permission can be used in the following way:
>>
>> allow domA_t domB_t : namespace { userns_create };
>
>
> Isn’t this actually domA_t domA_t : namespace . . .
>
> I got confused reading this initially trying to figure out what the second domain type would be, but looking at the code cleared that up.
Ah, good catch, thanks Karl!
--
paul-moore.com
Run_wrapper.rst was missing some command line arguments. Added
additional args in the file. Included all initial review comments.
Signed-off-by: Sadiya Kazi <sadiyakazi(a)google.com>
---
Documentation/dev-tools/kunit/run_wrapper.rst | 48 +++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/Documentation/dev-tools/kunit/run_wrapper.rst b/Documentation/dev-tools/kunit/run_wrapper.rst
index 5e560f2c5fca..91f5dda36e83 100644
--- a/Documentation/dev-tools/kunit/run_wrapper.rst
+++ b/Documentation/dev-tools/kunit/run_wrapper.rst
@@ -257,3 +257,51 @@ command line arguments:
added or modified. Instead, enable all tests
which have satisfied dependencies by adding
``CONFIG_KUNIT_ALL_TESTS=y`` to your ``.kunitconfig``.
+- ``--kunitconfig``: Specifies the path to the ``.kunitconfig`` file.
+ This Kconfig fragment enables KUnit tests. The "/.kunitconfig" gets
+ appended to the path specified. For example, If a directory path "lib/kunit"
+ is given, the complete path will be "lib/kunit/.kunitconfig".
+
+- ``--kconfig_add``: Specifies additional configuration options to be
+ appended to the ``.kunitconfig`` file. For example, ``CONFIG_KASAN=y``.
+
+- ``--arch``: Runs tests with the specified architecture. The architecture
+ specified must match the string passed to the ARCH make parameter.
+ For example, i386, x86_64, arm, um, etc. Non-UML architectures run on QEMU.
+ Default to 'um'.
+
+- ``--cross_compile``: Specifies the Kbuild toolchain. It passes the
+ same argument as passed to the ``CROSS_COMPILE`` variable used by
+ Kbuild. This will be the prefix for the toolchain
+ binaries such as GCC. For example:
+
+ - ``sparc64-linux-gnu`` if we have the sparc toolchain installed on
+ our system.
+
+ - ``$HOME/toolchains/microblaze/gcc-9.2.0-nolibc/microblaze-linux/bin/microblaze-linux``
+ if we have downloaded the microblaze toolchain from the 0-day
+ website to a specified path in our home directory called toolchains.
+
+- ``--qemu_config``: Specifies the path to the file containing a
+ custom qemu architecture definition. This should be a python file
+ containing a QemuArchParams object.
+
+- ``--qemu_args``: Specifies additional QEMU arguments, for example, "-smp 8".
+
+- ``--jobs``: Specifies the number of jobs (commands) to run simultaneously.
+ By default, this is set to the number of cores on your system.
+
+- ``--timeout``: Specifies the maximum number of seconds allowed for all tests to run.
+ This does not include the time taken to build the tests.
+
+- ``--kernel_args``: Specifies the kernel command-line arguments. Might be repeated.
+
+- ``--run_isolated``: If set, boots the kernel for each individual suite/test.
+ This is useful for debugging a non-hermetic test, one that
+ might pass/fail based on what ran before it.
+
+- ``--raw_output``: If set, generates unformatted output from kernel.
+ If set to ``--raw_output=kunit``, filters to just KUnit output.
+
+- ``--json``: If set, it stores the test results in a JSON format and prints to stdout or
+ saves to a file if a filename is specified.
--
2.37.0.170.g444d1eabd0-goog
Hello Dmitry Safonov,
The patch bc2652b7ae1e: "selftest/net/xfrm: Add test for ipsec
tunnel" from Sep 21, 2020, leads to the following Smatch static
checker warning:
tools/testing/selftests/net/ipsec.c:2294 main()
warn: impossible condition '(nr_process == 9223372036854775807) => (0-4294967295 == s64max)'
tools/testing/selftests/net/ipsec.c
2278 int main(int argc, char **argv)
2279 {
2280 unsigned int nr_process = 1;
2281 int route_sock = -1, ret = KSFT_SKIP;
2282 int test_desc_fd[2];
2283 uint32_t route_seq;
2284 unsigned int i;
2285
2286 if (argc > 2)
2287 exit_usage(argv);
2288
2289 if (argc > 1) {
2290 char *endptr;
2291
2292 errno = 0;
2293 nr_process = strtol(argv[1], &endptr, 10);
--> 2294 if ((errno == ERANGE && (nr_process == LONG_MAX || nr_process == LONG_MIN))
nr_process is a u32 so it can't be LONG_MIN/MAX. Do we even need to test
this or could we just fall through to the the > MAX_PROCESSES warning?
2295 || (errno != 0 && nr_process == 0)
2296 || (endptr == argv[1]) || (*endptr != '\0')) {
2297 printk("Failed to parse [nr_process]");
2298 exit_usage(argv);
2299 }
2300
2301 if (nr_process > MAX_PROCESSES || !nr_process) {
2302 printk("nr_process should be between [1; %u]",
2303 MAX_PROCESSES);
2304 exit_usage(argv);
2305 }
2306 }
2307
regards,
dan carpenter
The snprintf() function returns the number of bytes which *would*
have been copied if there were space. In other words, it can be
> sizeof(pin_path).
Fixes: c0fa1b6c3efc ("bpf: btf: Add BTF tests")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
---
tools/testing/selftests/bpf/prog_tests/btf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c b/tools/testing/selftests/bpf/prog_tests/btf.c
index 941b0100bafa..ef6528b8084c 100644
--- a/tools/testing/selftests/bpf/prog_tests/btf.c
+++ b/tools/testing/selftests/bpf/prog_tests/btf.c
@@ -5338,7 +5338,7 @@ static void do_test_pprint(int test_num)
ret = snprintf(pin_path, sizeof(pin_path), "%s/%s",
"/sys/fs/bpf", test->map_name);
- if (CHECK(ret == sizeof(pin_path), "pin_path %s/%s is too long",
+ if (CHECK(ret >= sizeof(pin_path), "pin_path %s/%s is too long",
"/sys/fs/bpf", test->map_name)) {
err = -1;
goto done;
--
2.35.1
Hi,
and after a little bit of time, here comes the v6 of the HID-BPF series.
Again, for a full explanation of HID-BPF, please refer to the last patch
in this series (23/23).
This version sees some improvements compared to v5 on top of the
usual addressing of the previous comments:
- now I think every eBPF core change has a matching selftest added
- the kfuncs declared in syscall can now actually access the memory of
the context
- the code to retrieve the BTF ID of the various HID hooks is much
simpler (just a plain use of the BTF_ID() API instead of
loading/unloading of a tracing program)
- I also added my HID Surface Dial example that I use locally to provide
a fuller example to users
Cheers,
Benjamin
Benjamin Tissoires (23):
selftests/bpf: fix config for CLS_BPF
bpf/verifier: allow kfunc to read user provided context
bpf/verifier: do not clear meta in check_mem_size
selftests/bpf: add test for accessing ctx from syscall program type
bpf/verifier: allow kfunc to return an allocated mem
selftests/bpf: Add tests for kfunc returning a memory pointer
bpf: prepare for more bpf syscall to be used from kernel and user
space.
libbpf: add map_get_fd_by_id and map_delete_elem in light skeleton
HID: core: store the unique system identifier in hid_device
HID: export hid_report_type to uapi
HID: convert defines of HID class requests into a proper enum
HID: initial BPF implementation
selftests/bpf: add tests for the HID-bpf initial implementation
HID: bpf: allocate data memory for device_event BPF programs
selftests/bpf/hid: add test to change the report size
HID: bpf: introduce hid_hw_request()
selftests/bpf: add tests for bpf_hid_hw_request
HID: bpf: allow to change the report descriptor
selftests/bpf: add report descriptor fixup tests
selftests/bpf: Add a test for BPF_F_INSERT_HEAD
samples/bpf: add new hid_mouse example
HID: bpf: add Surface Dial example
Documentation: add HID-BPF docs
Documentation/hid/hid-bpf.rst | 512 +++++++++
Documentation/hid/index.rst | 1 +
drivers/hid/Kconfig | 2 +
drivers/hid/Makefile | 2 +
drivers/hid/bpf/Kconfig | 19 +
drivers/hid/bpf/Makefile | 11 +
drivers/hid/bpf/entrypoints/Makefile | 88 ++
drivers/hid/bpf/entrypoints/README | 4 +
drivers/hid/bpf/entrypoints/entrypoints.bpf.c | 66 ++
.../hid/bpf/entrypoints/entrypoints.lskel.h | 682 ++++++++++++
drivers/hid/bpf/hid_bpf_dispatch.c | 554 ++++++++++
drivers/hid/bpf/hid_bpf_dispatch.h | 28 +
drivers/hid/bpf/hid_bpf_jmp_table.c | 577 ++++++++++
drivers/hid/hid-core.c | 49 +-
include/linux/bpf.h | 10 +-
include/linux/btf.h | 14 +
include/linux/hid.h | 38 +-
include/linux/hid_bpf.h | 145 +++
include/uapi/linux/hid.h | 26 +-
include/uapi/linux/hid_bpf.h | 25 +
kernel/bpf/btf.c | 67 +-
kernel/bpf/syscall.c | 10 +-
kernel/bpf/verifier.c | 67 +-
net/bpf/test_run.c | 23 +
samples/bpf/.gitignore | 2 +
samples/bpf/Makefile | 27 +
samples/bpf/hid_mouse.bpf.c | 134 +++
samples/bpf/hid_mouse.c | 150 +++
samples/bpf/hid_surface_dial.bpf.c | 161 +++
samples/bpf/hid_surface_dial.c | 216 ++++
tools/include/uapi/linux/hid.h | 62 ++
tools/include/uapi/linux/hid_bpf.h | 25 +
tools/lib/bpf/skel_internal.h | 23 +
tools/testing/selftests/bpf/Makefile | 5 +-
tools/testing/selftests/bpf/config | 5 +-
tools/testing/selftests/bpf/prog_tests/hid.c | 990 ++++++++++++++++++
.../selftests/bpf/prog_tests/kfunc_call.c | 68 ++
tools/testing/selftests/bpf/progs/hid.c | 206 ++++
.../selftests/bpf/progs/kfunc_call_test.c | 116 ++
39 files changed, 5150 insertions(+), 60 deletions(-)
create mode 100644 Documentation/hid/hid-bpf.rst
create mode 100644 drivers/hid/bpf/Kconfig
create mode 100644 drivers/hid/bpf/Makefile
create mode 100644 drivers/hid/bpf/entrypoints/Makefile
create mode 100644 drivers/hid/bpf/entrypoints/README
create mode 100644 drivers/hid/bpf/entrypoints/entrypoints.bpf.c
create mode 100644 drivers/hid/bpf/entrypoints/entrypoints.lskel.h
create mode 100644 drivers/hid/bpf/hid_bpf_dispatch.c
create mode 100644 drivers/hid/bpf/hid_bpf_dispatch.h
create mode 100644 drivers/hid/bpf/hid_bpf_jmp_table.c
create mode 100644 include/linux/hid_bpf.h
create mode 100644 include/uapi/linux/hid_bpf.h
create mode 100644 samples/bpf/hid_mouse.bpf.c
create mode 100644 samples/bpf/hid_mouse.c
create mode 100644 samples/bpf/hid_surface_dial.bpf.c
create mode 100644 samples/bpf/hid_surface_dial.c
create mode 100644 tools/include/uapi/linux/hid.h
create mode 100644 tools/include/uapi/linux/hid_bpf.h
create mode 100644 tools/testing/selftests/bpf/prog_tests/hid.c
create mode 100644 tools/testing/selftests/bpf/progs/hid.c
--
2.36.1
In rseq_test, there are two threads, which are vCPU thread and migration
worker separately. Unfortunately, the test has the wrong PID passed to
sched_setaffinity() in the migration worker. It forces migration on the
migration worker because zeroed PID represents the calling thread, which
is the migration worker itself. It means the vCPU thread is never enforced
to migration and it can migrate at any time, which eventually leads to
failure as the following logs show.
host# uname -r
5.19.0-rc6-gavin+
host# # cat /proc/cpuinfo | grep processor | tail -n 1
processor : 223
host# pwd
/home/gavin/sandbox/linux.main/tools/testing/selftests/kvm
host# for i in `seq 1 100`; do \
echo "--------> $i"; ./rseq_test; done
--------> 1
--------> 2
--------> 3
--------> 4
--------> 5
--------> 6
==== Test Assertion Failure ====
rseq_test.c:265: rseq_cpu == cpu
pid=3925 tid=3925 errno=4 - Interrupted system call
1 0x0000000000401963: main at rseq_test.c:265 (discriminator 2)
2 0x0000ffffb044affb: ?? ??:0
3 0x0000ffffb044b0c7: ?? ??:0
4 0x0000000000401a6f: _start at ??:?
rseq CPU = 4, sched CPU = 27
Fix the issue by passing correct parameter, TID of the vCPU thread, to
sched_setaffinity() in the migration worker.
Fixes: 61e52f1630f5 ("KVM: selftests: Add a test for KVM_RUN+rseq to detect task migration bugs")
Suggested-by: Sean Christopherson <seanjc(a)google.com>
Signed-off-by: Gavin Shan <gshan(a)redhat.com>
Reviewed-by: Oliver Upton <oliver.upton(a)linux.dev>
---
v4: Pick the code change as Sean suggested.
---
tools/testing/selftests/kvm/rseq_test.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/kvm/rseq_test.c b/tools/testing/selftests/kvm/rseq_test.c
index 4158da0da2bb..2237d1aac801 100644
--- a/tools/testing/selftests/kvm/rseq_test.c
+++ b/tools/testing/selftests/kvm/rseq_test.c
@@ -82,8 +82,9 @@ static int next_cpu(int cpu)
return cpu;
}
-static void *migration_worker(void *ign)
+static void *migration_worker(void *__rseq_tid)
{
+ pid_t rseq_tid = (pid_t)(unsigned long)__rseq_tid;
cpu_set_t allowed_mask;
int r, i, cpu;
@@ -106,7 +107,7 @@ static void *migration_worker(void *ign)
* stable, i.e. while changing affinity is in-progress.
*/
smp_wmb();
- r = sched_setaffinity(0, sizeof(allowed_mask), &allowed_mask);
+ r = sched_setaffinity(rseq_tid, sizeof(allowed_mask), &allowed_mask);
TEST_ASSERT(!r, "sched_setaffinity failed, errno = %d (%s)",
errno, strerror(errno));
smp_wmb();
@@ -231,7 +232,8 @@ int main(int argc, char *argv[])
vm = vm_create_default(VCPU_ID, 0, guest_code);
ucall_init(vm, NULL);
- pthread_create(&migration_thread, NULL, migration_worker, 0);
+ pthread_create(&migration_thread, NULL, migration_worker,
+ (void *)(unsigned long)gettid());
for (i = 0; !done; i++) {
vcpu_run(vm, VCPU_ID);
--
2.23.0
Hello Amit Daniel Kachhap,
The patch e9b60476bea0: "kselftest/arm64: Add utilities and a test to
validate mte memory" from Oct 2, 2020, leads to the following Smatch
static checker warning:
./tools/testing/selftests/arm64/mte/mte_common_util.c:336 mte_default_setup()
warn: bitwise AND condition is false here
./tools/testing/selftests/arm64/mte/mte_common_util.c
316 int mte_default_setup(void)
317 {
318 unsigned long hwcaps2 = getauxval(AT_HWCAP2);
319 unsigned long en = 0;
320 int ret;
321
322 if (!(hwcaps2 & HWCAP2_MTE)) {
323 ksft_print_msg("SKIP: MTE features unavailable\n");
324 return KSFT_SKIP;
325 }
326 /* Get current mte mode */
327 ret = prctl(PR_GET_TAGGED_ADDR_CTRL, en, 0, 0, 0);
328 if (ret < 0) {
329 ksft_print_msg("FAIL:prctl PR_GET_TAGGED_ADDR_CTRL with error =%d\n", ret);
330 return KSFT_FAIL;
331 }
332 if (ret & PR_MTE_TCF_SYNC)
333 mte_cur_mode = MTE_SYNC_ERR;
334 else if (ret & PR_MTE_TCF_ASYNC)
335 mte_cur_mode = MTE_ASYNC_ERR;
--> 336 else if (ret & PR_MTE_TCF_NONE)
It looks like the intent was to make PR_MTE_TCF_NONE into an ifdef
configurable thing but that never happened?
337 mte_cur_mode = MTE_NONE_ERR;
338
339 mte_cur_pstate_tco = mte_get_pstate_tco();
340 /* Disable PSTATE.TCO */
341 mte_disable_pstate_tco();
342 return 0;
343 }
regards,
dan carpenter
0Day/LKP observed that the kselftest blocks forever since one of the
pidfd_wait doesn't terminate in 1 of 30 runs. After digging into
the source, we found that it blocks at:
ASSERT_EQ(sys_waitid(P_PIDFD, pidfd, &info, WCONTINUED, NULL), 0);
wait_states has below testing flow:
CHILD PARENT
---------------+--------------
1 STOP itself
2 WAIT for CHILD STOPPED
3 SIGNAL CHILD to CONT
4 CONT
5 STOP itself
5' WAIT for CHILD CONT
6 WAIT for CHILD STOPPED
The problem is that the kernel cannot ensure the order of 5 and 5', once
5's goes first, the test will fail.
we can reproduce it by:
$ while true; do make run_tests -C pidfd; done
Introduce a blocking read in child process to make sure the parent can
check its WCONTINUED.
CC: Philip Li <philip.li(a)intel.com>
Reported-by: kernel test robot <lkp(a)intel.com>
Signed-off-by: Li Zhijian <lizhijian(a)fujitsu.com>
---
I have almost forgotten this patch since the former version post over 6 months
ago. This time I just do a rebase and update the comments.
V2: rewrite with pipe to avoid usleep
---
tools/testing/selftests/pidfd/pidfd_wait.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/tools/testing/selftests/pidfd/pidfd_wait.c b/tools/testing/selftests/pidfd/pidfd_wait.c
index 070c1c876df1..3f7bc6517dea 100644
--- a/tools/testing/selftests/pidfd/pidfd_wait.c
+++ b/tools/testing/selftests/pidfd/pidfd_wait.c
@@ -95,20 +95,27 @@ TEST(wait_states)
.flags = CLONE_PIDFD | CLONE_PARENT_SETTID,
.exit_signal = SIGCHLD,
};
+ int ret, pfd[2];
pid_t pid;
siginfo_t info = {
.si_signo = 0,
};
+ ASSERT_EQ(pipe(pfd), 0);
pid = sys_clone3(&args);
ASSERT_GE(pid, 0);
if (pid == 0) {
+ char buf[2];
+ close(pfd[1]);
kill(getpid(), SIGSTOP);
+ ASSERT_EQ(read(pfd[0], buf, 1), 1);
+ close(pfd[0]);
kill(getpid(), SIGSTOP);
exit(EXIT_SUCCESS);
}
+ close(pfd[0]);
ASSERT_EQ(sys_waitid(P_PIDFD, pidfd, &info, WSTOPPED, NULL), 0);
ASSERT_EQ(info.si_signo, SIGCHLD);
ASSERT_EQ(info.si_code, CLD_STOPPED);
@@ -117,6 +124,8 @@ TEST(wait_states)
ASSERT_EQ(sys_pidfd_send_signal(pidfd, SIGCONT, NULL, 0), 0);
ASSERT_EQ(sys_waitid(P_PIDFD, pidfd, &info, WCONTINUED, NULL), 0);
+ ASSERT_EQ(write(pfd[1], "C", 1), 1);
+ close(pfd[1]);
ASSERT_EQ(info.si_signo, SIGCHLD);
ASSERT_EQ(info.si_code, CLD_CONTINUED);
ASSERT_EQ(info.si_pid, parent_tid);
--
2.36.0
In rseq_test, there are two threads, which are vCPU thread and migration
worker separately. Unfortunately, the test has the wrong PID passed to
sched_setaffinity() in the migration worker. It forces migration on the
migration worker because zeroed PID represents the calling thread, which
is the migration worker itself. It means the vCPU thread is never enforced
to migration and it can migrate at any time, which eventually leads to
failure as the following logs show.
host# uname -r
5.19.0-rc6-gavin+
host# # cat /proc/cpuinfo | grep processor | tail -n 1
processor : 223
host# pwd
/home/gavin/sandbox/linux.main/tools/testing/selftests/kvm
host# for i in `seq 1 100`; do \
echo "--------> $i"; ./rseq_test; done
--------> 1
--------> 2
--------> 3
--------> 4
--------> 5
--------> 6
==== Test Assertion Failure ====
rseq_test.c:265: rseq_cpu == cpu
pid=3925 tid=3925 errno=4 - Interrupted system call
1 0x0000000000401963: main at rseq_test.c:265 (discriminator 2)
2 0x0000ffffb044affb: ?? ??:0
3 0x0000ffffb044b0c7: ?? ??:0
4 0x0000000000401a6f: _start at ??:?
rseq CPU = 4, sched CPU = 27
Fix the issue by passing correct parameter, TID of the vCPU thread, to
sched_setaffinity() in the migration worker.
Fixes: 61e52f1630f5 ("KVM: selftests: Add a test for KVM_RUN+rseq to detect task migration bugs")
Signed-off-by: Gavin Shan <gshan(a)redhat.com>
Reviewed-by: Oliver Upton <oliver.upton(a)linux.dev>
---
v3: Improved changelog (Oliver Upon)
---
tools/testing/selftests/kvm/rseq_test.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/rseq_test.c b/tools/testing/selftests/kvm/rseq_test.c
index 4158da0da2bb..c83ac7b467f8 100644
--- a/tools/testing/selftests/kvm/rseq_test.c
+++ b/tools/testing/selftests/kvm/rseq_test.c
@@ -38,6 +38,7 @@ static __thread volatile struct rseq __rseq = {
*/
#define NR_TASK_MIGRATIONS 100000
+static pid_t rseq_tid;
static pthread_t migration_thread;
static cpu_set_t possible_mask;
static int min_cpu, max_cpu;
@@ -106,7 +107,8 @@ static void *migration_worker(void *ign)
* stable, i.e. while changing affinity is in-progress.
*/
smp_wmb();
- r = sched_setaffinity(0, sizeof(allowed_mask), &allowed_mask);
+ r = sched_setaffinity(rseq_tid, sizeof(allowed_mask),
+ &allowed_mask);
TEST_ASSERT(!r, "sched_setaffinity failed, errno = %d (%s)",
errno, strerror(errno));
smp_wmb();
@@ -231,6 +233,7 @@ int main(int argc, char *argv[])
vm = vm_create_default(VCPU_ID, 0, guest_code);
ucall_init(vm, NULL);
+ rseq_tid = gettid();
pthread_create(&migration_thread, NULL, migration_worker, 0);
for (i = 0; !done; i++) {
--
2.23.0
In rseq_test, there are two threads, which are thread group leader
and migration worker. The migration worker relies on sched_setaffinity()
to force migration on the thread group leader. Unfortunately, we
have wrong parameter (0) passed to sched_getaffinity(). It's actually
forcing migration on the migration worker instead of the thread group
leader. It also means migration can happen on the thread group leader
at any time, which eventually leads to failure as the following logs
show.
host# uname -r
5.19.0-rc6-gavin+
host# # cat /proc/cpuinfo | grep processor | tail -n 1
processor : 223
host# pwd
/home/gavin/sandbox/linux.main/tools/testing/selftests/kvm
host# for i in `seq 1 100`; \
do echo "--------> $i"; ./rseq_test; done
--------> 1
--------> 2
--------> 3
--------> 4
--------> 5
--------> 6
==== Test Assertion Failure ====
rseq_test.c:265: rseq_cpu == cpu
pid=3925 tid=3925 errno=4 - Interrupted system call
1 0x0000000000401963: main at rseq_test.c:265 (discriminator 2)
2 0x0000ffffb044affb: ?? ??:0
3 0x0000ffffb044b0c7: ?? ??:0
4 0x0000000000401a6f: _start at ??:?
rseq CPU = 4, sched CPU = 27
This fixes the issue by passing correct parameter, tid of the group
thread leader, to sched_setaffinity().
Fixes: 61e52f1630f5 ("KVM: selftests: Add a test for KVM_RUN+rseq to detect task migration bugs")
Signed-off-by: Gavin Shan <gshan(a)redhat.com>
---
tools/testing/selftests/kvm/rseq_test.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/rseq_test.c b/tools/testing/selftests/kvm/rseq_test.c
index 4158da0da2bb..c83ac7b467f8 100644
--- a/tools/testing/selftests/kvm/rseq_test.c
+++ b/tools/testing/selftests/kvm/rseq_test.c
@@ -38,6 +38,7 @@ static __thread volatile struct rseq __rseq = {
*/
#define NR_TASK_MIGRATIONS 100000
+static pid_t rseq_tid;
static pthread_t migration_thread;
static cpu_set_t possible_mask;
static int min_cpu, max_cpu;
@@ -106,7 +107,8 @@ static void *migration_worker(void *ign)
* stable, i.e. while changing affinity is in-progress.
*/
smp_wmb();
- r = sched_setaffinity(0, sizeof(allowed_mask), &allowed_mask);
+ r = sched_setaffinity(rseq_tid, sizeof(allowed_mask),
+ &allowed_mask);
TEST_ASSERT(!r, "sched_setaffinity failed, errno = %d (%s)",
errno, strerror(errno));
smp_wmb();
@@ -231,6 +233,7 @@ int main(int argc, char *argv[])
vm = vm_create_default(VCPU_ID, 0, guest_code);
ucall_init(vm, NULL);
+ rseq_tid = gettid();
pthread_create(&migration_thread, NULL, migration_worker, 0);
for (i = 0; !done; i++) {
--
2.23.0
Hi Dear,
My name is Dr Lily William from the United States.I am a French and
American nationality (dual) living in the U.S and sometimes in France
for Work Purpose.
I hope you consider my friend request. I will share some of my pics
and more details about myself when I get your response.
Thanks
With love
Lily
On 7/18/22 04:02, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20220715:
>
on x86_64:
vmlinux.o: in function `ne_misc_dev_test_merge_phys_contig_memory_regions':
ne_misc_dev.c:(.text+0x88eae7): undefined reference to `kunit_kmalloc_array'
ld: ne_misc_dev.c:(.text+0x88eafd): undefined reference to `kunit_unary_assert_format'
ld: ne_misc_dev.c:(.text+0x88eb25): undefined reference to `kunit_do_failed_assertion'
ld: ne_misc_dev.c:(.text+0x88ec0c): undefined reference to `kunit_binary_assert_format'
ld: ne_misc_dev.c:(.text+0x88ec3c): undefined reference to `kunit_do_failed_assertion'
ld: ne_misc_dev.c:(.text+0x88ec58): undefined reference to `kunit_binary_assert_format'
ld: ne_misc_dev.c:(.text+0x88ec88): undefined reference to `kunit_do_failed_assertion'
ld: ne_misc_dev.c:(.text+0x88ecc2): undefined reference to `kunit_binary_assert_format'
ld: ne_misc_dev.c:(.text+0x88ecf2): undefined reference to `kunit_do_failed_assertion'
ld: ne_misc_dev.c:(.text+0x88ed19): undefined reference to `kunit_binary_assert_format'
ld: ne_misc_dev.c:(.text+0x88ed49): undefined reference to `kunit_do_failed_assertion'
ld: ne_misc_dev.c:(.text+0x88ed7e): undefined reference to `kunit_kfree'
Full randconfig file is attached.
--
~Randy
On Sat, Jul 16, 2022 at 09:14:08AM +0800, li_jessen2016(a)gmail.com li wrote:
> Thanks for your kind reply. Then what should I do? To officially raise a
> bug to all the relevant persons in the kernel community?
Yeah, I'd figure out who works on the script and mail them about it (or
develop a patch if you feel up to it!).
In rseq_test, there are two threads created. Those two threads are
'main' and 'migration_thread' separately. We also have the assumption
that non-migration status on 'migration-worker' thread guarantees the
same non-migration status on 'main' thread. Unfortunately, the assumption
isn't true. The 'main' thread can be migrated from one CPU to another
one between the calls to sched_getcpu() and READ_ONCE(__rseq.cpu_id).
The following assert is raised eventually because of the mismatched
CPU numbers.
The issue can be reproduced on arm64 system occasionally.
host# uname -r
5.19.0-rc6-gavin+
host# # cat /proc/cpuinfo | grep processor | tail -n 1
processor : 223
host# pwd
/home/gavin/sandbox/linux.main/tools/testing/selftests/kvm
host# for i in `seq 1 100`; \
do echo "--------> $i"; \
./rseq_test; sleep 3; \
done
--------> 1
--------> 2
--------> 3
--------> 4
--------> 5
--------> 6
==== Test Assertion Failure ====
rseq_test.c:265: rseq_cpu == cpu
pid=3925 tid=3925 errno=4 - Interrupted system call
1 0x0000000000401963: main at rseq_test.c:265 (discriminator 2)
2 0x0000ffffb044affb: ?? ??:0
3 0x0000ffffb044b0c7: ?? ??:0
4 0x0000000000401a6f: _start at ??:?
rseq CPU = 4, sched CPU = 27
This fixes the issue by double-checking on the current CPU after
call to READ_ONCE(__rseq.cpu_id) and restarting the test if the
two consecutive CPU numbers aren't euqal.
Fixes: 61e52f1630f5 ("KVM: selftests: Add a test for KVM_RUN+rseq to detect task migration bugs")
Signed-off-by: Gavin Shan <gshan(a)redhat.com>
---
tools/testing/selftests/kvm/rseq_test.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/kvm/rseq_test.c b/tools/testing/selftests/kvm/rseq_test.c
index 4158da0da2bb..74709dd9f5b2 100644
--- a/tools/testing/selftests/kvm/rseq_test.c
+++ b/tools/testing/selftests/kvm/rseq_test.c
@@ -207,7 +207,7 @@ int main(int argc, char *argv[])
{
int r, i, snapshot;
struct kvm_vm *vm;
- u32 cpu, rseq_cpu;
+ u32 cpu, rseq_cpu, last_cpu;
/* Tell stdout not to buffer its content */
setbuf(stdout, NULL);
@@ -259,8 +259,9 @@ int main(int argc, char *argv[])
smp_rmb();
cpu = sched_getcpu();
rseq_cpu = READ_ONCE(__rseq.cpu_id);
+ last_cpu = sched_getcpu();
smp_rmb();
- } while (snapshot != atomic_read(&seq_cnt));
+ } while (snapshot != atomic_read(&seq_cnt) || cpu != last_cpu);
TEST_ASSERT(rseq_cpu == cpu,
"rseq CPU = %d, sched CPU = %d\n", rseq_cpu, cpu);
--
2.23.0
Add a .kunitconfig file, which provides a default, working config for
running the KCSAN tests. Note that it needs to run on an SMP machine, so
to run under kunit_tool, the --qemu_args option should be used (on a
supported architecture, like x86_64). For example:
./tools/testing/kunit/kunit.py run --arch=x86_64 --qemu_args='-smp 8'
--kunitconfig=kernel/kcsan
Signed-off-by: David Gow <davidgow(a)google.com>
Reviewed-by: Marco Elver <elver(a)google.com>
Acked-by: Brendan Higgins <brendanhiggins(a)google.com>
---
kernel/kcsan/.kunitconfig | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 kernel/kcsan/.kunitconfig
diff --git a/kernel/kcsan/.kunitconfig b/kernel/kcsan/.kunitconfig
new file mode 100644
index 000000000000..e82f0f52ab0a
--- /dev/null
+++ b/kernel/kcsan/.kunitconfig
@@ -0,0 +1,24 @@
+# Note that the KCSAN tests need to run on an SMP setup.
+# Under kunit_tool, this can be done by using the --qemu_args
+# option to configure a machine with several cores. For example:
+# ./tools/testing/kunit/kunit.py run --kunitconfig=kernel/kcsan \
+# --arch=x86_64 --qemu_args="-smp 8"
+
+CONFIG_KUNIT=y
+
+CONFIG_DEBUG_KERNEL=y
+
+# Need some level of concurrency to test a concurrency sanitizer.
+CONFIG_SMP=y
+
+CONFIG_KCSAN=y
+CONFIG_KCSAN_KUNIT_TEST=y
+
+# Set these if you want to run test_barrier_nothreads
+#CONFIG_KCSAN_STRICT=y
+#CONFIG_KCSAN_WEAK_MEMORY=y
+
+# This prevents the test from timing out on many setups. Feel free to remove
+# (or alter) this, in conjunction with setting a different test timeout with,
+# for example, the --timeout kunit_tool option.
+CONFIG_KCSAN_REPORT_ONCE_IN_MS=100
--
2.37.0.170.g444d1eabd0-goog
On Fri, Jul 15, 2022 at 10:47:16PM +0800, li_jessen2016(a)gmail.com li wrote:
> FAIL: alsa/Makefile dependency check: $(shell
> FAIL: alsa/Makefile dependency check: pkg-config
..
> So I wonder why the FAIL info appears in the presence of *$(shell
> pkg-config --libs alsa) *in alsa/Makefile. Is it some sort of bug or
> did I miss something?
I think that's a bug in this tool you're running - it's not
understanding the $(shell ...) and generating false positives, not 100%
sure what it's trying to do but it's fairly clearly parsing every
element in the statement as a dependency of some kind.
Dzień dobry,
dostrzegam możliwość współpracy z Państwa firmą.
Świadczymy kompleksową obsługę inwestycji w fotowoltaikę, która obniża koszty energii elektrycznej nawet o 90%.
Czy są Państwo zainteresowani weryfikacją wstępnych propozycji?
Pozdrawiam,
Norbert Karecki
The use of kmap() is being deprecated in favor of kmap_local_page().
Two main problems with kmap(): (1) It comes with an overhead as mapping
space is restricted and protected by a global lock for synchronization and
(2) kmap() also requires global TLB invalidation when the kmap’s pool
wraps and it might block when the mapping space is fully utilized until a
slot becomes available.
kmap_local_page() is preferred over kmap() and kmap_atomic(). Where it
cannot mechanically replace the latters, code refactor should be considered
(special care must be taken if kernel virtual addresses are aliases in
different contexts).
With kmap_local_page() the mappings are per thread, CPU local, can take
page faults, and can be called from any context (including interrupts).
Call kmap_local_page() in firmware_loader wherever kmap() is currently
used. In firmware_rw() use the helpers copy_{from,to}_page() instead of
open coding the local mappings + memcpy().
Successfully tested with "firmware" selftests on a QEMU/KVM 32-bits VM
with 4GB RAM, booting a kernel with HIGHMEM64GB enabled.
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Luis Chamberlain <mcgrof(a)kernel.org>
Suggested-by: Ira Weiny <ira.weiny(a)intel.com>
Signed-off-by: Fabio M. De Francesco <fmdefrancesco(a)gmail.com>
---
v1->v2: According to the comments from Greg Kroah-Hartman (thanks!),
extend the commit message adding information about why kmap() should be
avoided. Delete an unused variable left in the code of v1, which has been
Reported-by: kernel test robot <lkp(a)intel.com>
drivers/base/firmware_loader/main.c | 4 ++--
drivers/base/firmware_loader/sysfs.c | 10 ++++------
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
index ac3f34e80194..7c3590fd97c2 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -435,11 +435,11 @@ static int fw_decompress_xz_pages(struct device *dev, struct fw_priv *fw_priv,
/* decompress onto the new allocated page */
page = fw_priv->pages[fw_priv->nr_pages - 1];
- xz_buf.out = kmap(page);
+ xz_buf.out = kmap_local_page(page);
xz_buf.out_pos = 0;
xz_buf.out_size = PAGE_SIZE;
xz_ret = xz_dec_run(xz_dec, &xz_buf);
- kunmap(page);
+ kunmap_local(xz_buf.out);
fw_priv->size += xz_buf.out_pos;
/* partial decompression means either end or error */
if (xz_buf.out_pos != PAGE_SIZE)
diff --git a/drivers/base/firmware_loader/sysfs.c b/drivers/base/firmware_loader/sysfs.c
index 5b0b85b70b6f..77bad32c481a 100644
--- a/drivers/base/firmware_loader/sysfs.c
+++ b/drivers/base/firmware_loader/sysfs.c
@@ -242,19 +242,17 @@ static void firmware_rw(struct fw_priv *fw_priv, char *buffer,
loff_t offset, size_t count, bool read)
{
while (count) {
- void *page_data;
int page_nr = offset >> PAGE_SHIFT;
int page_ofs = offset & (PAGE_SIZE - 1);
int page_cnt = min_t(size_t, PAGE_SIZE - page_ofs, count);
- page_data = kmap(fw_priv->pages[page_nr]);
-
if (read)
- memcpy(buffer, page_data + page_ofs, page_cnt);
+ memcpy_from_page(buffer, fw_priv->pages[page_nr],
+ page_ofs, page_cnt);
else
- memcpy(page_data + page_ofs, buffer, page_cnt);
+ memcpy_to_page(fw_priv->pages[page_nr], page_ofs,
+ buffer, page_cnt);
- kunmap(fw_priv->pages[page_nr]);
buffer += page_cnt;
offset += page_cnt;
count -= page_cnt;
--
2.37.0
Add a new QEMU config for kunit_tool, x86_64-smp, which provides an
8-cpu SMP setup. No other kunit_tool configurations provide an SMP
setup, so this is the best bet for testing things like KCSAN, which
require a multicore/multi-cpu system.
The choice of 8 CPUs is pretty arbitrary: it's enough to get tests like
KCSAN to run with a nontrivial number of worker threads, while still
working relatively quickly on older machines.
Signed-off-by: David Gow <davidgow(a)google.com>
---
This is based off the discussion in:
https://groups.google.com/g/kasan-dev/c/A7XzC2pXRC8
---
tools/testing/kunit/qemu_configs/x86_64-smp.py | 13 +++++++++++++
1 file changed, 13 insertions(+)
create mode 100644 tools/testing/kunit/qemu_configs/x86_64-smp.py
diff --git a/tools/testing/kunit/qemu_configs/x86_64-smp.py b/tools/testing/kunit/qemu_configs/x86_64-smp.py
new file mode 100644
index 000000000000..a95623f5f8b7
--- /dev/null
+++ b/tools/testing/kunit/qemu_configs/x86_64-smp.py
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0
+from ..qemu_config import QemuArchParams
+
+QEMU_ARCH = QemuArchParams(linux_arch='x86_64',
+ kconfig='''
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SMP=y
+ ''',
+ qemu_arch='x86_64',
+ kernel_path='arch/x86/boot/bzImage',
+ kernel_command_line='console=ttyS0',
+ extra_qemu_params=['-smp', '8'])
--
2.36.0.550.gb090851708-goog
The timer selftests are quite useful for me when enabling timers on new
SoCs, e.g. like now with the CMT timer on a Renesas R-Car S4-8. During
development, I needed these fixes and additions to make full use of
the tests. I think they make all sense upstream, so here they are.
Patches are based on v5.19-rc1. Looking forward to comments.
Happy hacking,
Wolfram
Wolfram Sang (9):
selftests: timers: valid-adjtimex: build fix for newer toolchains
selftests: timers: fix declarations of main()
selftests: timers: nanosleep: adapt to kselftest framework
selftests: timers: inconsistency-check: adapt to kselftest framework
selftests: timers: clocksource-switch: fix passing errors from child
selftests: timers: clocksource-switch: sort includes
selftests: timers: clocksource-switch: add command line switch to skip
sanity check
selftests: timers: clocksource-switch: add 'runtime' command line
parameter
selftests: timers: clocksource-switch: adapt to kselftest framework
tools/testing/selftests/timers/adjtick.c | 2 +-
tools/testing/selftests/timers/change_skew.c | 2 +-
.../selftests/timers/clocksource-switch.c | 70 ++++++++++++-------
.../selftests/timers/inconsistency-check.c | 32 +++++----
tools/testing/selftests/timers/nanosleep.c | 18 +++--
tools/testing/selftests/timers/raw_skew.c | 2 +-
.../selftests/timers/skew_consistency.c | 2 +-
.../testing/selftests/timers/valid-adjtimex.c | 2 +-
8 files changed, 80 insertions(+), 50 deletions(-)
--
2.35.1
When a nexthop is added, without a gw address, the default scope was set
to 'host'. Thus, when a source address is selected, 127.0.0.1 may be chosen
but rejected when the route is used.
When using a route without a nexthop id, the scope can be configured in the
route, thus the problem doesn't exist.
To explain more deeply: when a user creates a nexthop, it cannot specify
the scope. To create it, the function nh_create_ipv4() calls fib_check_nh()
with scope set to 0. fib_check_nh() calls fib_check_nh_nongw() wich was
setting scope to 'host'. Then, nh_create_ipv4() calls
fib_info_update_nhc_saddr() with scope set to 'host'. The src addr is
chosen before the route is inserted.
When a 'standard' route (ie without a reference to a nexthop) is added,
fib_create_info() calls fib_info_update_nhc_saddr() with the scope set by
the user. iproute2 set the scope to 'link' by default.
Here is a way to reproduce the problem:
ip netns add foo
ip -n foo link set lo up
ip netns add bar
ip -n bar link set lo up
sleep 1
ip -n foo link add name eth0 type dummy
ip -n foo link set eth0 up
ip -n foo address add 192.168.0.1/24 dev eth0
ip -n foo link add name veth0 type veth peer name veth1 netns bar
ip -n foo link set veth0 up
ip -n bar link set veth1 up
ip -n bar address add 192.168.1.1/32 dev veth1
ip -n bar route add default dev veth1
ip -n foo nexthop add id 1 dev veth0
ip -n foo route add 192.168.1.1 nhid 1
Try to get/use the route:
> $ ip -n foo route get 192.168.1.1
> RTNETLINK answers: Invalid argument
> $ ip netns exec foo ping -c1 192.168.1.1
> ping: connect: Invalid argument
Try without nexthop group (iproute2 sets scope to 'link' by dflt):
ip -n foo route del 192.168.1.1
ip -n foo route add 192.168.1.1 dev veth0
Try to get/use the route:
> $ ip -n foo route get 192.168.1.1
> 192.168.1.1 dev veth0 src 192.168.0.1 uid 0
> cache
> $ ip netns exec foo ping -c1 192.168.1.1
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.039 ms
>
> --- 192.168.1.1 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.039/0.039/0.039/0.000 ms
CC: stable(a)vger.kernel.org
Fixes: 597cfe4fc339 ("nexthop: Add support for IPv4 nexthops")
Reported-by: Edwin Brossette <edwin.brossette(a)6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
---
v2 -> v3:
- no change
v1 -> v2:
- remove useless arp off / fixed mac settings in the description
net/ipv4/fib_semantics.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index a57ba23571c9..20177ecf5bdd 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1230,7 +1230,7 @@ static int fib_check_nh_nongw(struct net *net, struct fib_nh *nh,
nh->fib_nh_dev = in_dev->dev;
dev_hold_track(nh->fib_nh_dev, &nh->fib_nh_dev_tracker, GFP_ATOMIC);
- nh->fib_nh_scope = RT_SCOPE_HOST;
+ nh->fib_nh_scope = RT_SCOPE_LINK;
if (!netif_carrier_ok(nh->fib_nh_dev))
nh->fib_nh_flags |= RTNH_F_LINKDOWN;
err = 0;
--
2.33.0
--
Dear,
I had sent you a mail but i don't think you received it that's why am
writing you again.It is important you get back to me as soon as you
can.
Abd-Wabbo Maddah
When a nexthop is added, without a gw address, the default scope was set
to 'host'. Thus, when a source address is selected, 127.0.0.1 may be chosen
but rejected when the route is used.
When using a route without a nexthop id, the scope can be configured in the
route, thus the problem doesn't exist.
To explain more deeply: when a user creates a nexthop, it cannot specify
the scope. To create it, the function nh_create_ipv4() calls fib_check_nh()
with scope set to 0. fib_check_nh() calls fib_check_nh_nongw() wich was
setting scope to 'host'. Then, nh_create_ipv4() calls
fib_info_update_nhc_saddr() with scope set to 'host'. The src addr is
chosen before the route is inserted.
When a 'standard' route (ie without a reference to a nexthop) is added,
fib_create_info() calls fib_info_update_nhc_saddr() with the scope set by
the user. iproute2 set the scope to 'link' by default.
Here is a way to reproduce the problem:
ip netns add foo
ip -n foo link set lo up
ip netns add bar
ip -n bar link set lo up
sleep 1
ip -n foo link add name eth0 type dummy
ip -n foo link set eth0 up
ip -n foo address add 192.168.0.1/24 dev eth0
ip -n foo link add name veth0 type veth peer name veth1 netns bar
ip -n foo link set veth0 up
ip -n bar link set veth1 up
ip -n bar address add 192.168.1.1/32 dev veth1
ip -n bar route add default dev veth1
ip -n foo nexthop add id 1 dev veth0
ip -n foo route add 192.168.1.1 nhid 1
Try to get/use the route:
> $ ip -n foo route get 192.168.1.1
> RTNETLINK answers: Invalid argument
> $ ip netns exec foo ping -c1 192.168.1.1
> ping: connect: Invalid argument
Try without nexthop group (iproute2 sets scope to 'link' by dflt):
ip -n foo route del 192.168.1.1
ip -n foo route add 192.168.1.1 dev veth0
Try to get/use the route:
> $ ip -n foo route get 192.168.1.1
> 192.168.1.1 dev veth0 src 192.168.0.1 uid 0
> cache
> $ ip netns exec foo ping -c1 192.168.1.1
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.039 ms
>
> --- 192.168.1.1 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.039/0.039/0.039/0.000 ms
CC: stable(a)vger.kernel.org
Fixes: 597cfe4fc339 ("nexthop: Add support for IPv4 nexthops")
Reported-by: Edwin Brossette <edwin.brossette(a)6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
---
v1 -> v2:
- remove useless arp off / fixed mac settings in the description
net/ipv4/fib_semantics.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index a57ba23571c9..20177ecf5bdd 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1230,7 +1230,7 @@ static int fib_check_nh_nongw(struct net *net, struct fib_nh *nh,
nh->fib_nh_dev = in_dev->dev;
dev_hold_track(nh->fib_nh_dev, &nh->fib_nh_dev_tracker, GFP_ATOMIC);
- nh->fib_nh_scope = RT_SCOPE_HOST;
+ nh->fib_nh_scope = RT_SCOPE_LINK;
if (!netif_carrier_ok(nh->fib_nh_dev))
nh->fib_nh_flags |= RTNH_F_LINKDOWN;
err = 0;
--
2.33.0
Earlier attempts to get "make O=build kselftest-all" to work were
not successful as they made undesirable changes to some functions
in the top-level Makefile. This series takes a different
approach by removing the root cause of the problem within
kselftest, which is when the sub-Makefile tries to install kernel
headers "backwards" by calling make with the top-level Makefile.
The actual issue comes from the fact that $(srctree) is ".." when
building in a sub-directory with "O=build" which then obviously
makes "-C $(top_srcdir)" point outside of the real source tree.
With this series, the generic kselftest targets work as expected
from the top level with or without a build directory e.g.:
$ make kselftest-all
$ make O=build kselftest-all
Then in order to build using the sub-Makefile explicitly, the
headers have to be installed first. This is arguably a valid
requirement to have when building a tool from a sub-Makefile.
For example, "make -C tools/testing/nvdimm/" fails in a similar
way until <asm/rwonce.h> has been generated by a kernel build.
v2: replace headers_install with headers
Guillaume Tucker (4):
selftests: drop khdr make target
selftests: stop using KSFT_KHDR_INSTALL
selftests: drop KSFT_KHDR_INSTALL make target
Makefile: add headers to kselftest targets
Makefile | 4 +-
tools/testing/selftests/Makefile | 28 +-------------
tools/testing/selftests/arm64/mte/Makefile | 1 -
tools/testing/selftests/arm64/signal/Makefile | 1 -
.../selftests/arm64/signal/test_signals.h | 4 +-
.../selftests/drivers/s390x/uvdevice/Makefile | 1 -
.../selftests/futex/functional/Makefile | 1 -
tools/testing/selftests/kvm/Makefile | 1 -
tools/testing/selftests/landlock/Makefile | 1 -
tools/testing/selftests/lib.mk | 38 -------------------
tools/testing/selftests/net/Makefile | 1 -
tools/testing/selftests/net/mptcp/Makefile | 1 -
tools/testing/selftests/tc-testing/Makefile | 1 -
tools/testing/selftests/vm/Makefile | 1 -
14 files changed, 5 insertions(+), 79 deletions(-)
--
2.30.2
Earlier attempts to get "make O=build kselftest-all" to work were
not successful as they made undesirable changes to some functions
in the top-level Makefile. This series takes a different
approach by removing the root cause of the problem within
kselftest, which is when the sub-Makefile tries to install kernel
headers "backwards" by calling make with the top-level Makefile.
The actual issue comes from the fact that $(srctree) is ".." when
building in a sub-directory with "O=build" which then obviously
makes "-C $(top_srcdir)" point outside of the real source tree.
With this series, the generic kselftest targets work as expected
from the top level with or without a build directory e.g.:
$ make kselftest-all
$ make O=build kselftest-all
Then in order to build using the sub-Makefile explicitly, the
headers have to be installed first. This is arguably a valid
requirement to have when building a tool from a sub-Makefile.
For example, "make -C tools/testing/nvdimm/" fails in a similar
way until <asm/rwonce.h> has been generated by a kernel build.
Guillaume Tucker (4):
selftests: drop khdr make target
selftests: stop using KSFT_KHDR_INSTALL
selftests: drop KSFT_KHDR_INSTALL make target
Makefile: add headers_install to kselftest targets
Makefile | 4 +-
tools/testing/selftests/Makefile | 28 +-------------
tools/testing/selftests/arm64/mte/Makefile | 1 -
tools/testing/selftests/arm64/signal/Makefile | 1 -
.../selftests/arm64/signal/test_signals.h | 4 +-
.../selftests/drivers/s390x/uvdevice/Makefile | 1 -
.../selftests/futex/functional/Makefile | 1 -
tools/testing/selftests/kvm/Makefile | 1 -
tools/testing/selftests/landlock/Makefile | 1 -
tools/testing/selftests/lib.mk | 38 -------------------
tools/testing/selftests/net/Makefile | 1 -
tools/testing/selftests/net/mptcp/Makefile | 1 -
tools/testing/selftests/tc-testing/Makefile | 1 -
tools/testing/selftests/vm/Makefile | 1 -
14 files changed, 5 insertions(+), 79 deletions(-)
--
2.30.2
One of the desirable features in security is the ability to restrict import
of data to a given system based on data authenticity. If data import can be
restricted, it would be possible to enforce a system-wide policy based on
the signing keys the system owner trusts.
This feature is widely used in the kernel. For example, if the restriction
is enabled, kernel modules can be plugged in only if they are signed with a
key whose public part is in the primary or secondary keyring.
For eBPF, it can be useful as well. For example, it might be useful to
authenticate data an eBPF program makes security decisions on.
After a discussion in the eBPF mailing list, it was decided that the stated
goal should be accomplished by introducing a new helper:
bpf_verify_pkcs7_signature(), dedicated to verify PKCS#7 signatures.
Other than the data and the signature, the helper also receives two
parameters for the keyring, which can be provided as alternatives: one is a
key pointer returned by the new bpf_lookup_user_key() helper, called with a
key serial possibly decided by the user; another is a pre-determined ID
among values defined in include/linux/verification.h.
While the first keyring-related parameter provides great flexibility, it
seems suboptimal in terms of security guarantees, as even if the eBPF
program is assumed to be trusted, the serial used to obtain the key pointer
might come from untrusted user space not choosing one that the system
administrator approves to enforce a mandatory policy.
The second keyring-related parameter instead provides much stronger
guarantees, especially if the pre-determined ID is not passed by user space
but is hardcoded in the eBPF program, and that program is signed. In this
case, bpf_verify_pkcs7_signature() will always perform signature
verification with a key that the system administrator approves, i.e. the
primary, secondary or platform keyring.
bpf_lookup_user_key() comes with the corresponding release helper
bpf_key_put(), to decrement the reference count of the key found with the
former helper. The eBPF verifier has been enhanced to ensure that the
release helper is always called whenever the acquire helper is called, or
otherwise refuses to load the program.
bpf_lookup_user_key() also accepts lookup-specific flags KEY_LOOKUP_CREATE
and KEY_LOOKUP_PARTIAL. Although these are most likely not useful for the
bpf_verify_pkcs7_signature(), newly defined flags could be.
bpf_lookup_user_key() does not request a particular permission to
lookup_user_key(), as it cannot determine it by itself. Also, it should not
get it from the user, as the user could pass an arbitrary value and use the
key for a different purpose. Instead, bpf_lookup_user_key() requests
KEY_DEFER_PERM_CHECK, and defers the permission check to the helper that
actually uses the key, in this patch set to bpf_verify_pkcs7_signature().
Since key_task_permission() is called by the PKCS#7 code during signature
verification, the only additional function bpf_verify_pkcs7_signature() has
to call is key_validate(). With that, the permission check can be
considered complete and equivalent, as it was done by bpf_lookup_user_key()
with the appropriate permission (in this case KEY_NEED_SEARCH).
All helpers can be called only from sleepable programs, because of memory
allocation (with lookup flag KEY_LOOKUP_CREATE) and crypto operations. For
example, the lsm.s/bpf attach point is suitable,
fexit/array_map_update_elem is not.
The correctness of implementation of the new helpers and of their usage is
checked with the introduced tests.
The patch set is organized as follows.
Patch 1 exports bpf_dynptr_get_size(), to obtain the real size of data
carried by a dynamic pointer. Patch 2 makes available for new eBPF helpers
some key-related definitions. Patch 3 introduces the bpf_lookup_user_key()
and bpf_key_put() helpers. Patch 4 introduces the
bpf_verify_pkcs7_signature(). Finally, patches 5-7 introduce the tests.
Changelog
v6:
- Switch back to key lookup helpers + signature verification (until v5),
and defer permission check from bpf_lookup_user_key() to
bpf_verify_pkcs7_signature()
- Add additional key lookup test to illustrate the usage of the
KEY_LOOKUP_CREATE flag and validate the flags (suggested by Daniel)
- Make description of flags of bpf_lookup_user_key() more user-friendly
(suggested by Daniel)
- Fix validation of flags parameter in bpf_lookup_user_key() (reported by
Daniel)
- Rename bpf_verify_pkcs7_signature() keyring-related parameters to
user_keyring and system_keyring to make their purpose more clear
- Accept keyring-related parameters of bpf_verify_pkcs7_signature() as
alternatives (suggested by KP)
- Replace unsigned long type with u64 in helper declaration (suggested by
Daniel)
- Extend the bpf_verify_pkcs7_signature() test by calling the helper
without data, by ensuring that the helper enforces the keyring-related
parameters as alternatives, by ensuring that the helper rejects
inaccessible and expired keyrings, and by checking all system keyrings
- Move bpf_lookup_user_key() and bpf_key_put() usage tests to
ref_tracking.c (suggested by John)
- Call bpf_lookup_user_key() and bpf_key_put() only in sleepable programs
v5:
- Move KEY_LOOKUP_ to include/linux/key.h
for validation of bpf_verify_pkcs7_signature() parameter
- Remove bpf_lookup_user_key() and bpf_key_put() helpers, and the
corresponding tests
- Replace struct key parameter of bpf_verify_pkcs7_signature() with the
keyring serial and lookup flags
- Call lookup_user_key() and key_put() in bpf_verify_pkcs7_signature()
code, to ensure that the retrieved key is used according to the
permission requested at lookup time
- Clarified keyring precedence in the description of
bpf_verify_pkcs7_signature() (suggested by John)
- Remove newline in the second argument of ASSERT_
- Fix helper prototype regular expression in bpf_doc.py
v4:
- Remove bpf_request_key_by_id(), don't return an invalid pointer that
other helpers can use
- Pass the keyring ID (without ULONG_MAX, suggested by Alexei) to
bpf_verify_pkcs7_signature()
- Introduce bpf_lookup_user_key() and bpf_key_put() helpers (suggested by
Alexei)
- Add lookup_key_norelease test, to ensure that the verifier blocks eBPF
programs which don't decrement the key reference count
- Parse raw PKCS#7 signature instead of module-style signature in the
verify_pkcs7_signature test (suggested by Alexei)
- Parse kernel module in user space and pass raw PKCS#7 signature to the
eBPF program for signature verification
v3:
- Rename bpf_verify_signature() back to bpf_verify_pkcs7_signature() to
avoid managing different parameters for each signature verification
function in one helper (suggested by Daniel)
- Use dynamic pointers and export bpf_dynptr_get_size() (suggested by
Alexei)
- Introduce bpf_request_key_by_id() to give more flexibility to the caller
of bpf_verify_pkcs7_signature() to retrieve the appropriate keyring
(suggested by Alexei)
- Fix test by reordering the gcc command line, always compile sign-file
- Improve helper support check mechanism in the test
v2:
- Rename bpf_verify_pkcs7_signature() to a more generic
bpf_verify_signature() and pass the signature type (suggested by KP)
- Move the helper and prototype declaration under #ifdef so that user
space can probe for support for the helper (suggested by Daniel)
- Describe better the keyring types (suggested by Daniel)
- Include linux/bpf.h instead of vmlinux.h to avoid implicit or
redeclaration
- Make the test selfcontained (suggested by Alexei)
v1:
- Don't define new map flag but introduce simple wrapper of
verify_pkcs7_signature() (suggested by Alexei and KP)
Roberto Sassu (7):
bpf: Export bpf_dynptr_get_size()
KEYS: Move KEY_LOOKUP_ to include/linux/key.h
bpf: Add bpf_lookup_user_key() and bpf_key_put() helpers
bpf: Add bpf_verify_pkcs7_signature() helper
selftests: Add verifier tests for bpf_lookup_user_key() and
bpf_key_put()
selftests/bpf: Add additional test for bpf_lookup_user_key()
selftests/bpf: Add test for bpf_verify_pkcs7_signature() helper
include/linux/bpf.h | 1 +
include/linux/key.h | 3 +
include/uapi/linux/bpf.h | 47 ++
kernel/bpf/bpf_lsm.c | 116 +++++
kernel/bpf/helpers.c | 2 +-
kernel/bpf/verifier.c | 6 +-
scripts/bpf_doc.py | 2 +
security/keys/internal.h | 2 -
tools/include/uapi/linux/bpf.h | 47 ++
tools/testing/selftests/bpf/Makefile | 14 +-
tools/testing/selftests/bpf/config | 2 +
.../bpf/prog_tests/lookup_user_key.c | 94 ++++
.../bpf/prog_tests/verify_pkcs7_sig.c | 410 ++++++++++++++++++
.../bpf/progs/test_lookup_user_key.c | 35 ++
.../bpf/progs/test_verify_pkcs7_sig.c | 90 ++++
tools/testing/selftests/bpf/test_verifier.c | 3 +-
.../selftests/bpf/verifier/ref_tracking.c | 66 +++
.../testing/selftests/bpf/verify_sig_setup.sh | 104 +++++
18 files changed, 1035 insertions(+), 9 deletions(-)
create mode 100644 tools/testing/selftests/bpf/prog_tests/lookup_user_key.c
create mode 100644 tools/testing/selftests/bpf/prog_tests/verify_pkcs7_sig.c
create mode 100644 tools/testing/selftests/bpf/progs/test_lookup_user_key.c
create mode 100644 tools/testing/selftests/bpf/progs/test_verify_pkcs7_sig.c
create mode 100755 tools/testing/selftests/bpf/verify_sig_setup.sh
--
2.25.1
It's possible that memory allocation for 'filtered' will fail, but for the
copy of the suite to succeed. In this case, the copy could be leaked.
Properly free 'copy' in the error case for the allocation of 'filtered'
failing.
Note that there may also have been a similar issue in
kunit_filter_subsuites, before it was removed in "kunit: flatten
kunit_suite*** to kunit_suite** in .kunit_test_suites".
This was reported by clang-analyzer via the kernel test robot, here:
https://lore.kernel.org/all/c8073b8e-7b9e-0830-4177-87c12f16349c@intel.com/
And by smatch via Dan Carpenter and the kernel test robot:
https://lore.kernel.org/all/202207101328.ASjx88yj-lkp@intel.com/
Fixes: a02353f49162 ("kunit: bail out of test filtering logic quicker if OOM")
Reported-by: kernel test robot <yujie.liu(a)intel.com>
Reported-by: kernel test robot <lkp(a)intel.com>
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Reviewed-by: Daniel Latypov <dlatypov(a)google.com>
Reviewed-by: Brendan Higgins <brendanhiggins(a)google.com>
Signed-off-by: David Gow <davidgow(a)google.com>
---
Thanks everyone! No actual code changes in v2, just fixes to the
description.
Changes since v1:
https://lore.kernel.org/all/20220712095627.1770312-1-davidgow@google.com/
- Fix a mistake in the commit description where we noted the allocation
for 'copy' could fail, instead of 'filtered'. (Thanks Yujie!)
- Noted in the description that smatch also found this (Thanks Dan!)
- Added the extra Reported-by and Reviewed-by tags.
---
lib/kunit/executor.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/kunit/executor.c b/lib/kunit/executor.c
index 6c489d6c5e5d..5e223327196a 100644
--- a/lib/kunit/executor.c
+++ b/lib/kunit/executor.c
@@ -74,8 +74,10 @@ kunit_filter_tests(const struct kunit_suite *const suite, const char *test_glob)
return ERR_PTR(-ENOMEM);
filtered = kcalloc(n + 1, sizeof(*filtered), GFP_KERNEL);
- if (!filtered)
+ if (!filtered) {
+ kfree(copy);
return ERR_PTR(-ENOMEM);
+ }
n = 0;
kunit_suite_for_each_test_case(suite, test_case) {
--
2.37.0.144.g8ac04bfd2-goog
It's possible that memory allocation for the copy will fail, but for the
copy of the suite to succeed. In this case, the copy could be leaked.
Properly free 'copy' in the error case for the allocation of 'filtered'
failing.
Note that there may also have been a similar issue in
kunit_filter_subsuites, before it was removed in "kunit: flatten
kunit_suite*** to kunit_suite** in .kunit_test_suites".
This was reported by clang-analyzer via the kernel test robot, here:
https://lore.kernel.org/all/c8073b8e-7b9e-0830-4177-87c12f16349c@intel.com/
Fixes: a02353f49162 ("kunit: bail out of test filtering logic quicker if OOM")
Reported-by: kernel test robot <yujie.liu(a)intel.com>
Signed-off-by: David Gow <davidgow(a)google.com>
---
lib/kunit/executor.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/kunit/executor.c b/lib/kunit/executor.c
index 6c489d6c5e5d..5e223327196a 100644
--- a/lib/kunit/executor.c
+++ b/lib/kunit/executor.c
@@ -74,8 +74,10 @@ kunit_filter_tests(const struct kunit_suite *const suite, const char *test_glob)
return ERR_PTR(-ENOMEM);
filtered = kcalloc(n + 1, sizeof(*filtered), GFP_KERNEL);
- if (!filtered)
+ if (!filtered) {
+ kfree(copy);
return ERR_PTR(-ENOMEM);
+ }
n = 0;
kunit_suite_for_each_test_case(suite, test_case) {
--
2.37.0.144.g8ac04bfd2-goog