tst_res.c: undefined symbol TEST_ERRNO by bmarcot · Pull Request #4 · linux-test-project/ltp

bmarcot · 2013-07-08T10:40:34Z

Get the correct error code from errno, instead of TEST_ERRNO.
(TEST_ERRNO is defined in lib/parse_opt.c if #ifdef UNIT_TEST)

Get the correct error code from errno, instead of TEST_ERRNO. (TEST_ERRNO is defined in lib/parse_opt.c if #ifdef UNIT_TEST)

bmarcot · 2013-07-08T16:25:23Z

Ok, that was eventually not a good fix as I looked at TEST_* macros.

Anyway, I am wondering where is defined TEST_ERRNO when compiling with make UCLINUX=1? Compiling with make UCLINUX=1 defines __USC_LIB__ which leads to the extern decralation of TEST_ERRNO in include/usctest.h. My problem is at this point, I can't find any definition for TEST_ERRNO...

Any insights welcomed, thanks!

metan-ucw · 2013-07-08T16:43:51Z

Hi!

Ok, that was eventually not a good fix as I looked at TEST_* macros.

Anyway, I am wondering where is defined TEST_ERRNO when compiling with make UCLINUX=1? Compiling with make UCLINUX=1 defines __USC_LIB__ which leads to the extern decralation of TEST_ERRNO in include/usctest.h. My problem is at this point, I can't find any definition for TEST_ERRNO...

Any insights welcomed, thanks!

Such topics are better discussed on the LTP mailing list.

LTP [email protected]

(More complicated patches are discussed and reviewed there too)

Cyril Hrubis
[email protected]

bmarcot · 2013-07-09T08:26:20Z

Hi Cyril,

Thank you for the redirection.

Benoit

This patch introduces wait so that testcases exit doesn't race with completion of aio_fsync. This is to avoid SIGSEGV: #0 0x000003fffd1f4a24 in _IO_flush_all_lockp () at genops.c:850 #1 0x000003fffd1f4b8e in _IO_cleanup () at genops.c:1010 #2 0x000003fffd1a88f6 in __run_exit_handlers () at exit.c:90 #3 0x000003fffd1a89b0 in __GI_exit () at exit.c:99 #4 0x000003fffd18c822 in __libc_start_main () at libc-start.c:292 #5 0x0000000080000b76 in _start () Signed-off-by: Jan Stancek <[email protected]> Acked-by: Cyril Hrubis <[email protected]> Reviewed-by: Wanlong Gao <[email protected]>

Test can hang during startup in following scenario: main new thread --------------------------------------------------+------------------------------------- int create_thread(int prio, pthread_t * tid) | ... | pthread_create(tid, &attr, thread_func, NULL);| while (!thread_started) { | | void *thread_func(void *data) | thread_started = 1; | pthread_cond_signal(&cond); pthread_mutex_lock(&c_mutex); | 132: pthread_cond_wait(&cond, &c_mutex); | |65: pthread_mutex_lock(&mutex); | (gdb) bt #0 0x00007fd588808f6d in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007fd588804d31 in _L_lock_790 () from /lib64/libpthread.so.0 #2 0x00007fd588804c37 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000400bba in thread_func (data=0x0) at ../../../conformance/interfaces/pthread_attr_setschedpolicy/2-1.c:65 #4 0x00007fd588802de3 in start_thread () from /lib64/libpthread.so.0 #5 0x00007fd5885300dd in clone () from /lib64/libc.so.6 (gdb) t 2 (gdb) bt #0 0x00007fd5888066f5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x0000000000400d9b in create_thread (prio=5, tid=0x7fffdb562678) at ../../../conformance/interfaces/pthread_attr_setschedpolicy/2-1.c:132 #2 0x0000000000400e82 in main () at ../../../conformance/interfaces/pthread_attr_setschedpolicy/2-1.c:174 Fix this by using same c_mutex in thread_func for updating thread_started and signalling cond. Signed-off-by: Jan Stancek <[email protected]>

If request is already in progress, wait for it to complete, so it doesn't race with exit of testcase (aiocb is allocated on main's stack), to avoid aio_cancel_1-1 and 2-1 sporadically crashing. For example: Core was generated by `./aio_cancel_2-1.run-test '. Program terminated with signal 11, Segmentation fault. (gdb) bt #0 0x00003fffa6e81158 in __GI__exit (status=0) #1 0x00003fffa6df3054 in __run_exit_handlers (...) #2 0x00003fffa6df3134 in __GI_exit (status=<optimized out>) #3 0x00003fffa6dd4588 in generic_start_main (main=0x10000bbc ...) #4 0x00003fffa6dd4774 in __libc_start_main (...) #5 0x0000000000000000 in ?? () Signed-off-by: Jan Stancek <[email protected]> Acked-by: Cyril Hrubis <[email protected]>

Description of Problem: There is a race condition if we map a same file on different processes. Region tracking is protected by mmap_sem and hugetlb_instantiation_mutex. When we do mmap, we don't grab a hugetlb_instantiation_mutex, but only mmap_sem (exclusively). This doesn't prevent other tasks from modifying the region structure, so it can be modified by two processes concurrently. Testcase hugemmap06.c is the trigger to cause system crash: crash> bt -s PID: 4492 TASK: ffff88033e437520 CPU: 2 COMMAND: "hugemmap06" #0 [ffff88033dbb3960] machine_kexec+395 at ffffffff8103d1ab #1 [ffff88033dbb39c0] crash_kexec+114 at ffffffff810cc4f2 #2 [ffff88033dbb3a90] oops_end+192 at ffffffff8153c840 #3 [ffff88033dbb3ac0] die+91 at ffffffff81010f5b #4 [ffff88033dbb3af0] do_general_protection+338 at ffffffff8153c332 #5 [ffff88033dbb3b20] general_protection+37 at ffffffff8153bb05 [exception RIP: list_del+40] RIP: ffffffff812a3598 RSP: ffff88033dbb3bd8 RFLAGS: 00010292 RAX: dead000000100100 RBX: ffff88013cf37340 RCX: 0000000000002dc2 RDX: dead000000200200 RSI: 0000000000000046 RDI: 0000000000000009 RBP: ffff88033dbb3be8 R8: 0000000000015598 R9: 0000000000000000 R10: 000000000000000f R11: 0000000000000009 R12: 000000000000000a R13: ffff88033d64b9e8 R14: ffff88033e5b9720 R15: ffff88013cf37340 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0000 #6 [ffff88033dbb3bf0] region_add+154 at ffffffff811698da #7 [ffff88033dbb3c40] alloc_huge_page+669 at ffffffff8116a61d #8 [ffff88033dbb3ce0] hugetlb_fault+1083 at ffffffff8116b9bb #9 [ffff88033dbb3d90] handle_mm_fault+917 at ffffffff81153295 #10 [ffff88033dbb3e00] __do_page_fault+326 at ffffffff8104f156 #11 [ffff88033dbb3f20] do_page_fault+62 at ffffffff8153e78e #12 [ffff88033dbb3f50] page_fault+37 at ffffffff8153bb35 RIP: 00000000004027c6 RSP: 00007f7cadef9e80 RFLAGS: 00010297 RAX: 000000005a49238f RBX: 00007ffcb2d19320 RCX: 000000357498e084 RDX: 000000357498e0b0 RSI: 00007f7cadef9e5c RDI: 000000357498e4e0 RBP: 0000000000000008 R8: 000000357498e0a0 R9: 000000357498e100 R10: 00007f7cadefa9d0 R11: 0000000000000206 R12: 0000000000000007 R13: 0000000000000002 R14: 0000000000000003 R15: 00002aaaac000000 ORIG_RAX: ffffffffffffffff CS: 0033 SS: 002b The fix are all these below commits: f522c3ac00(mm, hugetlb: change variable name reservations to resv) 9119a41e90(mm, hugetlb: unify region structure handling) 7b24d8616b(mm, hugetlb: fix race in region tracking) 1406ec9ba6(mm, hugetlb: improve, cleanup resv_map parameters) Signed-off-by: Li Wang <[email protected]> Signed-off-by: Jan Stancek <[email protected]>

This test was using sbrk() to position MAP_FIXED mappings, which creates problems when something extends heap prior to test. For example: sbrk(0) is 0x13d8000 heap is extended in call to tst_tmpdir() mkdir("/tmp/mmaXIz1uo", 0700) = 0 brk(0) = 0x13d8000 brk(0x13f9000) = 0x13f9000 brk(0) = 0x13f9000 test starts mapping/writing to areas it shouldn't: mmap(0x13de000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED, 3, 0x8000) = 0x13de000 mmap(0x13e5000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED, 3, 0xa000) = 0x13e5000 mmap(0x13ea000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED, 3, 0xa000) = 0x13ea000 which results in crash: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7aa57a0 in __memset_sse2 () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install glibc-2.17-161.el7.x86_64 (gdb) bt #0 0x00007ffff7aa57a0 in __memset_sse2 () from /lib64/libc.so.6 #1 0x00007ffff7a99ba2 in _int_malloc () from /lib64/libc.so.6 #2 0x00007ffff7a9bfbc in malloc () from /lib64/libc.so.6 #3 0x00007ffff7ad65c1 in __alloc_dir () from /lib64/libc.so.6 #4 0x00000000004031d8 in rmobj (obj=0x61e010 "/tmp/mmaLheQvJ", errmsg=errmsg@entry=0x7fffffffe0f8) at tst_tmpdir.c:145 #5 0x00000000004038cd in tst_rmdir () at tst_tmpdir.c:335 #6 0x0000000000402cf6 in main (argc=<optimized out>, argv=0x7fffffffe328) at mmapstress04.c:278 This patch rewrites test in newlib style. It also drops initial offset parameter as it isn't used by any runtest. LARGE_FILE ifdefs have been dropped as we can easily enable _64 build if needed. Mapping file as MAP_FIXED doesn't seem to be necessary, but I decided to adhere to original. Signed-off-by: Jan Stancek <[email protected]> Acked-by: Cyril Hrubis <[email protected]>

Only newlib testcases support SAFE macros in cleanup(). When SAFE_UNLINK fails, it creates infinite loop between tst_brk_ and cleanup: #0 tst_res__ at tst_res.c:153 #1 0x0000000000407ba8 in tst_brk__ at tst_res.c:480 #2 0x00000000004081fe in tst_brkm_ at tst_res.c:577 #3 0x000000000040a7c9 in safe_unlink at safe_macros.c:358 #4 0x0000000000404abd in cleanup () at pipeio.c:497 #5 0x0000000000407bc7 in tst_brk__ at tst_res.c:498 #6 0x00000000004081fe in tst_brkm_ at tst_res.c:577 #7 0x000000000040c1d6 in def_handler at tst_sig.c:231 #8 <signal handler called> #9 0x00007f29c2cbd1f7 in __GI_raise at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #10 0x00007f29c2cbe8e8 in __GI_abort () at abort.c:90 #11 0x00000000004081af in tst_brkm_ at tst_res.c:581 #12 0x000000000040a7c9 in safe_unlink at safe_macros.c:358 #13 0x0000000000404abd in cleanup () at pipeio.c:497 #14 0x0000000000407bc7 in tst_brk__ at tst_res.c:498 #15 0x00000000004081fe in tst_brkm_ at tst_res.c:577 #16 0x000000000040c1d6 in def_handler at tst_sig.c:231 #17 <signal handler called> #18 0x00007f29c2cbd1f7 in __GI_raise at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #19 0x00007f29c2cbe8e8 in __GI_abort () at abort.c:90 #20 0x00000000004081af in tst_brkm_ at tst_res.c:581 #21 0x000000000040a7c9 in safe_unlink at safe_macros.c:358 #22 0x0000000000404abd in cleanup () at pipeio.c:497 ... Signed-off-by: Jan Stancek <[email protected]>

Testcases which spawn children via clone(CLONE_VM) are prone to races in dynamic linker during symbol resolution. CLONE_VM is causing both parent and child process to share same TLS, which rarely leads to a crashes, for example: Program terminated with signal 4, Illegal instruction. [Switching to thread 1 (LWP 30351)] (gdb) bt #0 _dl_x86_64_restore_sse () at ../sysdeps/x86_64/dl-trampoline.S:389 #1 0x00007fefa1360625 in _dl_fixup (l=<optimized out>, reloc_arg=<optimized out>) at ../elf/dl-runtime.c:121 #2 0x00007fefa13670c0 in _dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:87 #3 0x0000000000402e4f in test_FILES () at clone02.c:332 #4 child_fn () at clone02.c:272 #5 0x00007fefa10887ad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 [Switching to thread 2 (LWP 30350)] (gdb) bt #0 0x00007fefa104f1f2 in __libc_wait (stat_loc=stat_loc@entry=0x7ffe0edb537c) at ../sysdeps/unix/sysv/linux/wait.c:30 #1 0x000000000040294a in main (ac=<optimized out>, av=<optimized out>) at clone02.c:154 See also: http://www.mail-archive.com/[email protected]/msg01944.html Signed-off-by: Jan Stancek <[email protected]> Acked-by: Cyril Hrubis <[email protected]>

Test checks if vsyscall and vdso VMAs are reported correctly. vsyscall range and permissions were fixed with kernel commit 103efcd9aac1 ("fix perms/range of vsyscall vma in /proc/*/maps"). While some newer systems run with CONFIG_LEGACY_VSYSCALL_NONE, this test may serve to find regressions on systems still running with vsyscalls. Second part of the test checks regression of vdso permissions bug (fixed with b6558c4a2378 ("fix [vdso] page permissions") and e5b97dde514f ("add VM_ALWAYSDUMP")). As a consequence of this bug, vdso pages were not included in core dumps which caused incomplete backtraces: Program terminated with signal 11, Segmentation fault. #0 0x005f0402 in ?? () Thread 1 (process 14859): #0 0x005f0402 in ?? () linux-test-project#1 0x00336366 in ?? () from /lib/i686/nosegneg/libc.so.6 linux-test-project#2 0x0804845f in handle_alrm (signo=14) at small.c:9 linux-test-project#3 0x005f0420 in ?? () linux-test-project#4 0x0000000e in ?? () linux-test-project#5 0x00000033 in ?? () linux-test-project#6 0x00000000 in ?? () Signed-off-by: Veronika Kabatova <[email protected]>

Test checks if vsyscall and vdso VMAs are reported correctly. vsyscall range and permissions were fixed with kernel commit 103efcd9aac1 ("fix perms/range of vsyscall vma in /proc/*/maps"). While some newer systems run with CONFIG_LEGACY_VSYSCALL_NONE, this test may serve to find regressions on systems still running with vsyscalls. Second part of the test checks regression of vdso permissions bug (fixed with b6558c4a2378 ("fix [vdso] page permissions") and e5b97dde514f ("add VM_ALWAYSDUMP")). As a consequence of this bug, vdso pages were not included in core dumps which caused incomplete backtraces: Program terminated with signal 11, Segmentation fault. #0 0x005f0402 in ?? () Thread 1 (process 14859): #0 0x005f0402 in ?? () #1 0x00336366 in ?? () from /lib/i686/nosegneg/libc.so.6 #2 0x0804845f in handle_alrm (signo=14) at small.c:9 #3 0x005f0420 in ?? () #4 0x0000000e in ?? () #5 0x00000033 in ?? () #6 0x00000000 in ?? () Signed-off-by: Veronika Kabatova <[email protected]> Signed-off-by: Cyril Hrubis <[email protected]>

After Linux upstream commit cd9ff4de0107 ("ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY") the kernel maps neighbour keys for loopback device to INADDR_ANY, therefore test #4 fails because it can't find "127.6.6.6" entry. Use the defined LTP test interface for this test-case instead of loopback device. Signed-off-by: Alexey Kodanev <[email protected]>

There haven't been any major changes to this test in years, so presumably something in recent glibc changed, that exposed this problem. I confirmed with glibc-2.28, that this test can hang quite reliably on 2 CPU KVM guest. It reproduces easier with smaller number of loops for child_mapper() and overall test runtime reduced (-p 20 -t 0.02). The problem is that childs' signal handler and main function both call exit(), which can deadlock on __exit_funcs_lock: #0 0x00007f0619d72f8c in __lll_lock_wait_private () from /lib64/libc.so.6 #1 0x00007f0619ca2f4b in __run_exit_handlers () from /lib64/libc.so.6 #2 0x00007f0619ca3160 in exit () from /lib64/libc.so.6 #3 0x00000000004039d8 in clean_mapper (sig=<optimized out>) at mmapstress10.c:898 #4 <signal handler called> #5 0x00007f0619ca2fbd in __run_exit_handlers () from /lib64/libc.so.6 #6 0x00007f0619ca3160 in exit () from /lib64/libc.so.6 #7 0x0000000000403e7f in child_mapper (file=file@entry=0x40f530 "mmapstress10.out", procno=<optimized out>, nprocs=nprocs@entry=20) at mmapstress10.c:676 #8 0x0000000000403833 in main (argc=<optimized out>, argv=<optimized out>) at mmapstress10.c:458 Switch all signal handlers to _exit(). Signed-off-by: Jan Stancek <[email protected]> Acked-by: Cyril Hrubis <[email protected]>

runltp_ng(ssh): Allow ssh key authentication

Assigning the memory prefetch resource to virtio-pci might fail on VM guests. For example on Oracle cloud instance (describing itself as "Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.4.1 12/03/2020"): test_pci 76 TFAIL : tpci.c:73: PCI bus 00 slot 20 : Test-case '12' In dmesg: ltp_tpci: test-case 12 ltp_tpci: assign resources ltp_tpci: assign resource #0 ltp_tpci: name = 0000:00:04.0, flags = 262401, start 0xc000, end 0xc03f ltp_tpci: assign resource linux-test-project#1 ltp_tpci: name = 0000:00:04.0, flags = 262656, start 0xc1010000, end 0xc1010fff ltp_tpci: assign resource linux-test-project#2 ltp_tpci: name = 0000:00:04.0, flags = 0, start 0x0, end 0x0 ltp_tpci: assign resource linux-test-project#3 ltp_tpci: name = 0000:00:04.0, flags = 0, start 0x0, end 0x0 ltp_tpci: assign resource linux-test-project#4 ltp_tpci: name = 0000:00:04.0, flags = 538190348, start 0x800004000, end 0x800007fff virtio-pci 0000:00:04.0: BAR 4: no space for [mem size 0x00004000 64bit pref] virtio-pci 0000:00:04.0: BAR 4: failed to assign [mem size 0x00004000 64bit pref] Signed-off-by: Krzysztof Kozlowski <[email protected]> --- Found the failure on multiple different kernels in different cloud providers (Oracle, AWS, Azure): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1878389

Assigning the memory prefetch resource to virtio-pci might fail on VM guests. For example on Oracle cloud instance (describing itself as "Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.4.1 12/03/2020"): test_pci 76 TFAIL : tpci.c:73: PCI bus 00 slot 20 : Test-case '12' In dmesg: ltp_tpci: test-case 12 ltp_tpci: assign resources ltp_tpci: assign resource #0 ltp_tpci: name = 0000:00:04.0, flags = 262401, start 0xc000, end 0xc03f ltp_tpci: assign resource linux-test-project#1 ltp_tpci: name = 0000:00:04.0, flags = 262656, start 0xc1010000, end 0xc1010fff ltp_tpci: assign resource linux-test-project#2 ltp_tpci: name = 0000:00:04.0, flags = 0, start 0x0, end 0x0 ltp_tpci: assign resource linux-test-project#3 ltp_tpci: name = 0000:00:04.0, flags = 0, start 0x0, end 0x0 ltp_tpci: assign resource linux-test-project#4 ltp_tpci: name = 0000:00:04.0, flags = 538190348, start 0x800004000, end 0x800007fff virtio-pci 0000:00:04.0: BAR 4: no space for [mem size 0x00004000 64bit pref] virtio-pci 0000:00:04.0: BAR 4: failed to assign [mem size 0x00004000 64bit pref] ltp_tpci: assign resource to '4', ret '-12' ltp_tpci: assign resource linux-test-project#5 ltp_tpci: name = (null), flags = 0, start 0x0, end 0x0 ltp_tpci: assign resource linux-test-project#6 ltp_tpci: name = 0000:00:04.0, flags = 0, start 0x0, end 0x0 Signed-off-by: Krzysztof Kozlowski <[email protected]> --- Found the failure on multiple different kernels in different cloud providers (Oracle, AWS, Azure): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1878389

Assigning the memory prefetch resource to virtio-pci might fail on VM guests. For example on Oracle cloud instance (describing itself as "Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.4.1 12/03/2020"): test_pci 76 TFAIL : tpci.c:73: PCI bus 00 slot 20 : Test-case '12' In dmesg: ltp_tpci: test-case 12 ltp_tpci: assign resources ltp_tpci: assign resource #0 ltp_tpci: name = 0000:00:04.0, flags = 262401, start 0xc000, end 0xc03f ltp_tpci: assign resource linux-test-project#1 ltp_tpci: name = 0000:00:04.0, flags = 262656, start 0xc1010000, end 0xc1010fff ltp_tpci: assign resource linux-test-project#2 ltp_tpci: name = 0000:00:04.0, flags = 0, start 0x0, end 0x0 ltp_tpci: assign resource linux-test-project#3 ltp_tpci: name = 0000:00:04.0, flags = 0, start 0x0, end 0x0 ltp_tpci: assign resource linux-test-project#4 ltp_tpci: name = 0000:00:04.0, flags = 538190348, start 0x800004000, end 0x800007fff virtio-pci 0000:00:04.0: BAR 4: no space for [mem size 0x00004000 64bit pref] virtio-pci 0000:00:04.0: BAR 4: failed to assign [mem size 0x00004000 64bit pref] Signed-off-by: Krzysztof Kozlowski <[email protected]>

Assigning the memory prefetch resource to virtio-pci might fail on VM guests. For example on Oracle cloud instance (describing itself as "Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.4.1 12/03/2020"): test_pci 76 TFAIL : tpci.c:73: PCI bus 00 slot 20 : Test-case '12' In dmesg: ltp_tpci: test-case 12 ltp_tpci: assign resources ltp_tpci: assign resource #0 ltp_tpci: name = 0000:00:04.0, flags = 262401, start 0xc000, end 0xc03f ltp_tpci: assign resource linux-test-project#1 ltp_tpci: name = 0000:00:04.0, flags = 262656, start 0xc1010000, end 0xc1010fff ltp_tpci: assign resource linux-test-project#2 ltp_tpci: name = 0000:00:04.0, flags = 0, start 0x0, end 0x0 ltp_tpci: assign resource linux-test-project#3 ltp_tpci: name = 0000:00:04.0, flags = 0, start 0x0, end 0x0 ltp_tpci: assign resource linux-test-project#4 ltp_tpci: name = 0000:00:04.0, flags = 538190348, start 0x800004000, end 0x800007fff virtio-pci 0000:00:04.0: BAR 4: no space for [mem size 0x00004000 64bit pref] virtio-pci 0000:00:04.0: BAR 4: failed to assign [mem size 0x00004000 64bit pref] ltp_tpci: assign resource to '4', ret '-12' ltp_tpci: assign resource linux-test-project#5 ltp_tpci: name = (null), flags = 0, start 0x0, end 0x0 ltp_tpci: assign resource linux-test-project#6 ltp_tpci: name = 0000:00:04.0, flags = 0, start 0x0, end 0x0 Signed-off-by: Krzysztof Kozlowski <[email protected]> --- Found the failure on multiple different kernels in different cloud providers (Oracle, AWS, Azure): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1878389

Assigning the memory prefetch resource to virtio-pci might fail on VM guests. For example on Oracle cloud instance (describing itself as "Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.4.1 12/03/2020"): test_pci 76 TFAIL : tpci.c:73: PCI bus 00 slot 20 : Test-case '12' In dmesg: ltp_tpci: test-case 12 ltp_tpci: assign resources ltp_tpci: assign resource #0 ltp_tpci: name = 0000:00:04.0, flags = 262401, start 0xc000, end 0xc03f ltp_tpci: assign resource linux-test-project#1 ltp_tpci: name = 0000:00:04.0, flags = 262656, start 0xc1010000, end 0xc1010fff ltp_tpci: assign resource linux-test-project#2 ltp_tpci: name = 0000:00:04.0, flags = 0, start 0x0, end 0x0 ltp_tpci: assign resource linux-test-project#3 ltp_tpci: name = 0000:00:04.0, flags = 0, start 0x0, end 0x0 ltp_tpci: assign resource linux-test-project#4 ltp_tpci: name = 0000:00:04.0, flags = 538190348, start 0x800004000, end 0x800007fff virtio-pci 0000:00:04.0: BAR 4: no space for [mem size 0x00004000 64bit pref] virtio-pci 0000:00:04.0: BAR 4: failed to assign [mem size 0x00004000 64bit pref] Signed-off-by: Krzysztof Kozlowski <[email protected]>

Test started failing with recent glibc (glibc-2.34.9000-38.fc36), which detects that buffer in pread is potentially too small: tst_test.c:1431: TINFO: Timeout per run is 0h 05m 00s *** buffer overflow detected ***: terminated tst_test.c:1484: TBROK: Test killed by SIGIOT/SIGABRT! (gdb) bt #0 __pthread_kill_implementation at pthread_kill.c:44 linux-test-project#1 0x00007ffff7e46f73 in __pthread_kill_internal at pthread_kill.c:78 linux-test-project#2 0x00007ffff7df6a36 in __GI_raise at ../sysdeps/posix/raise.c:26 linux-test-project#3 0x00007ffff7de082f in __GI_abort () at abort.c:79 linux-test-project#4 0x00007ffff7e3b01e in __libc_message at ../sysdeps/posix/libc_fatal.c:155 linux-test-project#5 0x00007ffff7ed945a in __GI___fortify_fail at fortify_fail.c:26 linux-test-project#6 0x00007ffff7ed7dc6 in __GI___chk_fail () at chk_fail.c:28 linux-test-project#7 0x00007ffff7ed8214 in __pread_chk at pread_chk.c:26 linux-test-project#8 0x0000000000404d1a in pread at /usr/include/bits/unistd.h:74 linux-test-project#9 verify_pread (n=<optimized out>) at pread02.c:44 linux-test-project#10 0x000000000040dc19 in run_tests () at tst_test.c:1246 linux-test-project#11 testrun () at tst_test.c:1331 linux-test-project#12 fork_testrun () at tst_test.c:1462 linux-test-project#13 0x000000000040e9a1 in tst_run_tcases linux-test-project#14 0x0000000000404bde in main Extend it to number of bytes we are trying to read from fd. Signed-off-by: Jan Stancek <[email protected]> Acked-by: Petr Vorel <[email protected]>

Test started failing with recent glibc (glibc-2.34.9000-38.fc36), which detects that buffer in pread is potentially too small: tst_test.c:1431: TINFO: Timeout per run is 0h 05m 00s *** buffer overflow detected ***: terminated tst_test.c:1484: TBROK: Test killed by SIGIOT/SIGABRT! (gdb) bt #0 __pthread_kill_implementation at pthread_kill.c:44 #1 0x00007ffff7e46f73 in __pthread_kill_internal at pthread_kill.c:78 #2 0x00007ffff7df6a36 in __GI_raise at ../sysdeps/posix/raise.c:26 #3 0x00007ffff7de082f in __GI_abort () at abort.c:79 #4 0x00007ffff7e3b01e in __libc_message at ../sysdeps/posix/libc_fatal.c:155 #5 0x00007ffff7ed945a in __GI___fortify_fail at fortify_fail.c:26 #6 0x00007ffff7ed7dc6 in __GI___chk_fail () at chk_fail.c:28 #7 0x00007ffff7ed8214 in __pread_chk at pread_chk.c:26 #8 0x0000000000404d1a in pread at /usr/include/bits/unistd.h:74 #9 verify_pread (n=<optimized out>) at pread02.c:44 #10 0x000000000040dc19 in run_tests () at tst_test.c:1246 #11 testrun () at tst_test.c:1331 #12 fork_testrun () at tst_test.c:1462 #13 0x000000000040e9a1 in tst_run_tcases #14 0x0000000000404bde in main Extend it to number of bytes we are trying to read from fd. Signed-off-by: Jan Stancek <[email protected]> Acked-by: Petr Vorel <[email protected]> Reviewed-by: Cyril Hrubis <[email protected]>

The maximum field width of a string conversion does not include the null byte. So we can overflow the buffer by one byte. This can be triggered in ioctl_loop01 with -fsanitize=address even if the file contents are far less than the buffer size: tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s tst_device.c:93: TINFO: Found free device 1 '/dev/loop1' ioctl_loop01.c:85: TPASS: /sys/block/loop1/loop/partscan = 0 ioctl_loop01.c:86: TPASS: /sys/block/loop1/loop/autoclear = 0 ================================================================= ==293==ERROR: AddressSanitizer: stack-buffer-overflow on address 0xf5c03420 at pc 0xf7952bf8 bp 0xff9cf9f8 sp 0xff9cf5d0 WRITE of size 1025 at 0xf5c03420 thread T0 #0 0xf7952bf7 (/lib/libasan.so.8+0x89bf7) (BuildId: f8d5331e88e5c1b8a8a55eda0a8e20503ea0d2b9) #1 0xf7953879 in __isoc99_vfscanf (/lib/libasan.so.8+0x8a879) (BuildId: f8d5331e88e5c1b8a8a55eda0a8e20503ea0d2b9) #2 0x8071f85 in safe_file_scanf /home/rich/qa/ltp/lib/safe_file_ops.c:139 #3 0x80552ea in tst_assert_str /home/rich/qa/ltp/lib/tst_assert.c:60 #4 0x804f17a in verify_ioctl_loop /home/rich/qa/ltp/testcases/kernel/syscalls/ioctl/ioctl_loop01.c:87 #5 0x8061599 in run_tests /home/rich/qa/ltp/lib/tst_test.c:1380 #6 0x8061599 in testrun /home/rich/qa/ltp/lib/tst_test.c:1463 #7 0x8061599 in fork_testrun /home/rich/qa/ltp/lib/tst_test.c:1592 #8 0x806877a in tst_run_tcases /home/rich/qa/ltp/lib/tst_test.c:1686 #9 0x804e01b in main ../../../../include/tst_test.h:394 #10 0xf7188294 in __libc_start_call_main (/lib/libc.so.6+0x23294) (BuildId: 87c7a50c8792985dd164f5af2d45b8e91d9f4391) #11 0xf7188357 in __libc_start_main@@GLIBC_2.34 (/lib/libc.so.6+0x23357) (BuildId: 87c7a50c8792985dd164f5af2d45b8e91d9f4391) #12 0x804e617 in _start ../sysdeps/i386/start.S:111 Address 0xf5c03420 is located in stack of thread T0 at offset 1056 in frame #0 0x805525f in tst_assert_str /home/rich/qa/ltp/lib/tst_assert.c:57 This frame has 1 object(s): [32, 1056) 'sys_val' (line 58) <== Memory access at offset 1056 overflows this variable Fixes: f4919b1 ("lib: Add TST_ASSERT_FILE_INT and TST_ASSERT_FILE_STR") Reviewed-by: Cyril Hrubis <[email protected]> Reviewed-by: Petr Vorel <[email protected]> Signed-off-by: Richard Palethorpe <[email protected]>

On Intel sapphire rapids server, BIOS could allocate one memory block for CXL node when the server boot up, and this node "MemUsed" is 0 when CXL is not used like as follow: " cat /sys/devices/system/node/node2/meminfo Node 2 MemTotal: 4194304 kB Node 2 MemFree: 4194304 kB Node 2 MemUsed: 0 kB ... " And it caused get_mempolicy01/02 and set_mempolicy01/02/03/04 cases to fail like as follow sample: " tag=get_mempolicy01 stime=1683272855 cmdline="get_mempolicy01" contacts="" analysis=exit <<<test_output>>> incrementing stop tst_test.c:1560: TINFO: Timeout per run is 0h 00m 30s tst_numa.c:200: TINFO: Found 3 NUMA memory nodes tst_numa.c:165: TWARN: Failed to parse '/sys/devices/system/node/node2/meminfo' get_mempolicy01.c:188: TINFO: test #1: policy: MPOL_DEFAULT, no target get_mempolicy01.c:191: TPASS: policy: MPOL_DEFAULT, no target passed get_mempolicy01.c:188: TINFO: test #2: policy: MPOL_BIND get_mempolicy01.c:191: TPASS: policy: MPOL_BIND passed get_mempolicy01.c:188: TINFO: test #3: policy: MPOL_INTERLEAVE get_mempolicy01.c:191: TPASS: policy: MPOL_INTERLEAVE passed get_mempolicy01.c:188: TINFO: test #4: policy: MPOL_PREFERRED, no target get_mempolicy01.c:191: TPASS: policy: MPOL_PREFERRED, no target passed get_mempolicy01.c:188: TINFO: test #5: policy: MPOL_PREFERRED get_mempolicy01.c:191: TPASS: policy: MPOL_PREFERRED passed get_mempolicy01.c:188: TINFO: test #6: policy: MPOL_DEFAULT, flags: MPOL_F_ADDR, no target get_mempolicy01.c:191: TPASS: policy: MPOL_DEFAULT, flags: MPOL_F_ADDR, no target passed get_mempolicy01.c:188: TINFO: test #7: policy: MPOL_BIND, flags: MPOL_F_ADDR get_mempolicy01.c:191: TPASS: policy: MPOL_BIND, flags: MPOL_F_ADDR passed get_mempolicy01.c:188: TINFO: test #8: policy: MPOL_INTERLEAVE, flags: MPOL_F_ADDR get_mempolicy01.c:191: TPASS: policy: MPOL_INTERLEAVE, flags: MPOL_F_ADDR passed get_mempolicy01.c:188: TINFO: test #9: policy: MPOL_PREFERRED, flags: MPOL_F_ADDR, no target get_mempolicy01.c:191: TPASS: policy: MPOL_PREFERRED, flags: MPOL_F_ADDR, no target passed get_mempolicy01.c:188: TINFO: test #10: policy: MPOL_PREFERRED, flags: MPOL_F_ADDR get_mempolicy01.c:191: TPASS: policy: MPOL_PREFERRED, flags: MPOL_F_ADDR passed Summary: passed 10 failed 0 broken 0 skipped 0 warnings 1 ... -------- ------ ---------- get_mempolicy01 FAIL 4 " So fixed the fake failure when CXL node memory is not being used. Signed-off-by: Pengfei Xu <[email protected]> Signed-off-by: Cyril Hrubis <[email protected]>

63e8c1e introduced a regression on 32 bit compilation when compiled with -fstack-protector-strong, because struct timespec is probably too small for timespec64. PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig CFLAGS="-m32 -fstack-protector-strong" LDFLAGS="-m32 -fstack-protector-strong" ./configure ... # gdb ./abort01 (gdb) set follow-fork-mode child (gdb) run Starting program: testcases/kernel/syscalls/abort/abort01 Missing separate debuginfos, use: zypper install glibc-32bit-debuginfo-2.31-150300.52.2.x86_64 tst_test.c:1690: TINFO: LTP version: 20230929-7-gff6cdc67f tst_test.c:1576: TINFO: Timeout per run is 0h 00m 30s [Attaching after process 3357 fork to child process 3360] [New inferior 2 (process 3360)] [Detaching after fork from parent process 3357] [Inferior 1 (process 3357) detached] *** stack smashing detected ***: terminated Thread 2.1 "abort01" received signal SIGABRT, Aborted. [Switching to process 3360] 0xf7fd2559 in __kernel_vsyscall () (gdb) bt #0 0xf7fd2559 in __kernel_vsyscall () linux-test-project#1 0xf7e08aa2 in raise () from /lib/libc.so.6 linux-test-project#2 0xf7e09efd in abort () from /lib/libc.so.6 linux-test-project#3 0xf7e4d91b in __libc_message () from /lib/libc.so.6 linux-test-project#4 0xf7eeb2cc in __fortify_fail () from /lib/libc.so.6 linux-test-project#5 0xf7eeb299 in __stack_chk_fail () from /lib/libc.so.6 linux-test-project#6 0x0805c501 in syscall_supported_by_kernel (sysnr=403) at tst_clocks.c:27 linux-test-project#7 0x0805c80d in tst_clock_gettime (clk_id=1, ts=0x807cfb0 <tst_start_time>) at tst_clocks.c:66 linux-test-project#8 0x080531df in heartbeat () at tst_test.c:1374 linux-test-project#9 0x08053ba2 in testrun () at tst_test.c:1458 linux-test-project#10 fork_testrun () at tst_test.c:1608 linux-test-project#11 0x08055afa in tst_run_tcases (argc=<optimized out>, argv=<optimized out>, self=<optimized out>) at tst_test.c:1704 linux-test-project#12 0x0804b3f0 in main (argc=1, argv=0xffffc414) at ../../../../include/tst_test.h:401 (gdb) Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Fixes: 63e8c1e ("tst_clocks: Fix unaddressable byte warning") Reported-by: Petr Cervinka <[email protected]> Suggested-by: Cyril Hrubis <[email protected]> Signed-off-by: Petr Vorel <[email protected]>

63e8c1e introduced a regression on 32 bit compilation when compiled with -fstack-protector-strong, because struct timespec is probably too small for timespec64. PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig CFLAGS="-m32 -fstack-protector-strong" LDFLAGS="-m32 -fstack-protector-strong" ./configure ... # gdb ./abort01 (gdb) set follow-fork-mode child (gdb) run Starting program: testcases/kernel/syscalls/abort/abort01 Missing separate debuginfos, use: zypper install glibc-32bit-debuginfo-2.31-150300.52.2.x86_64 tst_test.c:1690: TINFO: LTP version: 20230929-7-gff6cdc67f tst_test.c:1576: TINFO: Timeout per run is 0h 00m 30s [Attaching after process 3357 fork to child process 3360] [New inferior 2 (process 3360)] [Detaching after fork from parent process 3357] [Inferior 1 (process 3357) detached] *** stack smashing detected ***: terminated Thread 2.1 "abort01" received signal SIGABRT, Aborted. [Switching to process 3360] 0xf7fd2559 in __kernel_vsyscall () (gdb) bt #0 0xf7fd2559 in __kernel_vsyscall () linux-test-project#1 0xf7e08aa2 in raise () from /lib/libc.so.6 linux-test-project#2 0xf7e09efd in abort () from /lib/libc.so.6 linux-test-project#3 0xf7e4d91b in __libc_message () from /lib/libc.so.6 linux-test-project#4 0xf7eeb2cc in __fortify_fail () from /lib/libc.so.6 linux-test-project#5 0xf7eeb299 in __stack_chk_fail () from /lib/libc.so.6 linux-test-project#6 0x0805c501 in syscall_supported_by_kernel (sysnr=403) at tst_clocks.c:27 linux-test-project#7 0x0805c80d in tst_clock_gettime (clk_id=1, ts=0x807cfb0 <tst_start_time>) at tst_clocks.c:66 linux-test-project#8 0x080531df in heartbeat () at tst_test.c:1374 linux-test-project#9 0x08053ba2 in testrun () at tst_test.c:1458 linux-test-project#10 fork_testrun () at tst_test.c:1608 linux-test-project#11 0x08055afa in tst_run_tcases (argc=<optimized out>, argv=<optimized out>, self=<optimized out>) at tst_test.c:1704 linux-test-project#12 0x0804b3f0 in main (argc=1, argv=0xffffc414) at ../../../../include/tst_test.h:401 (gdb) Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Fixes: 63e8c1e ("tst_clocks: Fix unaddressable byte warning") Link: https://lore.kernel.org/ltp/[email protected]/ Reported-by: Petr Cervinka <[email protected]> Suggested-by: Cyril Hrubis <[email protected]> Signed-off-by: Petr Vorel <[email protected]>

63e8c1e introduced a regression on 32 bit compilation when compiled with -fstack-protector-strong, because struct timespec is probably too small for timespec64. PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig CFLAGS="-m32 -fstack-protector-strong" LDFLAGS="-m32 -fstack-protector-strong" ./configure ... # gdb ./abort01 (gdb) set follow-fork-mode child (gdb) run Starting program: testcases/kernel/syscalls/abort/abort01 Missing separate debuginfos, use: zypper install glibc-32bit-debuginfo-2.31-150300.52.2.x86_64 tst_test.c:1690: TINFO: LTP version: 20230929-7-gff6cdc67f tst_test.c:1576: TINFO: Timeout per run is 0h 00m 30s [Attaching after process 3357 fork to child process 3360] [New inferior 2 (process 3360)] [Detaching after fork from parent process 3357] [Inferior 1 (process 3357) detached] *** stack smashing detected ***: terminated Thread 2.1 "abort01" received signal SIGABRT, Aborted. [Switching to process 3360] 0xf7fd2559 in __kernel_vsyscall () (gdb) bt #0 0xf7fd2559 in __kernel_vsyscall () #1 0xf7e08aa2 in raise () from /lib/libc.so.6 #2 0xf7e09efd in abort () from /lib/libc.so.6 #3 0xf7e4d91b in __libc_message () from /lib/libc.so.6 #4 0xf7eeb2cc in __fortify_fail () from /lib/libc.so.6 #5 0xf7eeb299 in __stack_chk_fail () from /lib/libc.so.6 #6 0x0805c501 in syscall_supported_by_kernel (sysnr=403) at tst_clocks.c:27 #7 0x0805c80d in tst_clock_gettime (clk_id=1, ts=0x807cfb0 <tst_start_time>) at tst_clocks.c:66 #8 0x080531df in heartbeat () at tst_test.c:1374 #9 0x08053ba2 in testrun () at tst_test.c:1458 #10 fork_testrun () at tst_test.c:1608 #11 0x08055afa in tst_run_tcases (argc=<optimized out>, argv=<optimized out>, self=<optimized out>) at tst_test.c:1704 #12 0x0804b3f0 in main (argc=1, argv=0xffffc414) at ../../../../include/tst_test.h:401 (gdb) Test timeouted, sending SIGKILL! Test timeouted, sending SIGKILL! Fixes: 63e8c1e ("tst_clocks: Fix unaddressable byte warning") Reported-by: Petr Cervinka <[email protected]> Suggested-by: Cyril Hrubis <[email protected]> Reviewed-by: Marius Kittler <[email protected]> Signed-off-by: Petr Vorel <[email protected]>

And skip EFAULT for glibc as it can segfault in VDSO: #0 __arch_chacha20_blocks_nostack () at arch/x86/entry/vdso/vgetrandom-chacha.S:146 146 movups state0,0x00(output) (gdb) bt #0 __arch_chacha20_blocks_nostack () at arch/x86/entry/vdso/vgetrandom-chacha.S:146 #1 0x00007fcd3ce6417a in __cvdso_getrandom_data (rng_info=0x7fcd3ce5f280, buffer=0xffffffffffffffff, len=64, flags=1, opaque_state=0x7fcd3ce5df00, opaque_len=<optimized out>) at arch/x86/entry/vdso/../../../../lib/vdso/getrandom.c:237 #2 __cvdso_getrandom (buffer=<optimized out>, len=64, flags=1, opaque_state=0x7fcd3ce5df00, opaque_len=<optimized out>) at arch/x86/entry/vdso/../../../../lib/vdso/getrandom.c:259 #3 __vdso_getrandom (buffer=0xffffffffffffffff, len=64, flags=1, opaque_state=0x7fcd3ce5df00, opaque_len=<optimized out>) at arch/x86/entry/vdso/vgetrandom.c:11 #4 0x00007fcd3cc7faf3 in getrandom_vdso (buffer=0xffffffffffffffff, length=64, flags=0, cancel=<optimized out>) at ../sysdeps/unix/sysv/linux/getrandom.c:204 #5 0x0000000000401ff7 in verify_getrandom (i=0) at getrandom05.c:40 Signed-off-by: Jan Stancek <[email protected]> Reviewed-by: Cyril Hrubis <[email protected]> Reviewed-by: Li Wang <[email protected]>

tst_res.c: undefined symbol TEST_ERRNO

bab1084

Get the correct error code from errno, instead of TEST_ERRNO. (TEST_ERRNO is defined in lib/parse_opt.c if #ifdef UNIT_TEST)

bmarcot closed this Jul 8, 2013

Revaj mentioned this pull request Jun 13, 2017

general_mail_tests.sh fails because a mismatch on the results #164

Closed

leishaoting mentioned this pull request Sep 22, 2017

the case of mail is fail on debian6.2.0-3 leishaoting/ltp#1

Open

cfconrad pushed a commit to cfconrad/ltp that referenced this pull request Oct 9, 2018

Merge pull request linux-test-project#4 from cfconrad/runltp_ng_sshkey

91951f8

runltp_ng(ssh): Allow ssh key authentication

rafaeldtinoco mentioned this pull request Jan 24, 2019

vma05.sh - false positives for vDSO bug detection #477

Open

chetjain mentioned this pull request Apr 25, 2019

pcrypt_aead01 crashing the LPAR #525

Closed

juexinformac mentioned this pull request Aug 23, 2023

ltp_tpci: testcase 12 related to virtio releasing and reassigning resource leads to guest hung #1061

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

tst_res.c: undefined symbol TEST_ERRNO#4

tst_res.c: undefined symbol TEST_ERRNO#4
bmarcot wants to merge 1 commit intolinux-test-project:masterfrom
bmarcot:master

bmarcot commented Jul 8, 2013

Uh oh!

bmarcot commented Jul 8, 2013

Uh oh!

metan-ucw commented Jul 8, 2013

Uh oh!

bmarcot commented Jul 9, 2013

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

bmarcot commented Jul 8, 2013

Uh oh!

bmarcot commented Jul 8, 2013

Uh oh!

metan-ucw commented Jul 8, 2013

Uh oh!

bmarcot commented Jul 9, 2013

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants