Restore corrupted data file #2

chrisdearman · 2012-10-19T00:29:19Z

Previous patch to add missing newlines to files modified
a file which contains binary data.

Signed-off-by: Chris Dearman chris@mips.com

Previous patch to add missing newlines to files modified a file which contains binary data. Signed-off-by: Chris Dearman <chris@mips.com>

gaowanlong · 2012-10-19T01:35:31Z

I have no floppy device on my machine, so untested, but I think restore this binary contained file is right.
So I would merge this.

Thanks,
Wanlong Gao

-Restore corrupted data file

This testcase crashed in about 1/200 of runs on s390x system with 2 CPUs: Core was generated by `./7-1.run-test'. Program terminated with signal 11, Segmentation fault. #0 _dl_fini () at dl-fini.c:228 228 if (l->l_init_called) (gdb) bt #0 _dl_fini () at dl-fini.c:228 #1 0x000003fffd345c62 in __run_exit_handlers (status=<optimized out>, listp=0x3fffd4b4a78 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:77 #2 0x000003fffd345ca4 in __GI_exit (status=<optimized out>) at exit.c:99 #3 0x000003fffd3294e6 in __libc_start_main (main=0x80000b18 <main>, argc=<optimized out>, ubp_av=0x3ffff970108, init=<optimized out>, fini=0x80000d4c <__libc_csu_fini>, rtld_fini=0x3fffd50821c <_dl_fini>, stack_end=0x3ffff970050) at libc-start.c:257 #4 0x0000000080000a26 in _start () (gdb) x/1x l 0x9fd4f2918: Cannot access memory at address 0x9fd4f2918 The crash was presumably caused by race, where variable defined in main() got out of scope before operation started by aio_read() completed. Patched version succesfully made 100000 iterations. Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>

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 <jstancek@redhat.com> Acked-by: Cyril Hrubis <chrubis@suse.cz> Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>

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 <jstancek@redhat.com>

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 <jstancek@redhat.com> Acked-by: Cyril Hrubis <chrubis@suse.cz>

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 <liwang@redhat.com> Signed-off-by: Jan Stancek <jstancek@redhat.com>

checkpoint_wake is currently sleeping also in case when it wakes up all processes. This creates problem for combination of checkpoints and process_state_wait, because it creates false impression, that child is sleeping on operation following checkpoint_wake (#2), while it really sleeps inside checkpoint_wake (#1). child parent TST_CHECKPOINT_WAKE #1 TST_CHECKPOINT_WAIT TST_PROCESS_STATE_WAIT(child, 'S') kill(child, SIGINT) sleep() #2 This patch avoids sleep in checkpoint_wake if all processes has been already woken up. Signed-off-by: Jan Stancek <jstancek@redhat.com> Acked-by: Cyril Hrubis <chrubis@suse.cz>

These case occasionally failed on RHEL platform: numa02 2 TFAIL : ltpapicmd.c:200: Test #2: NUMA hit and othernode increase in node0 is less than expected numa03 3 TFAIL : ltpapicmd.c:200: Test #3: NUMA interleave hit in node0 is less than expected numa08 8 TFAIL : ltpapicmd.c:200: Test #8: NUMA interleave hit in node0 is less than expected From git log (commit e439df0), it says "In RHEL collection of istics take more time", and add sleep 2s in the case. I looked into the detail and found that's reasonable, numastat growing slowly on RHEL system, therefore tests failed with numastate update uncompleted. Despite all that, sleeping 2 sec still working bad during my test. In this patch, reconstruct the whole tests in a new method which detect numa statistics more precisely by command 'numastat -p $pid'. The worth to say, I take use of Cyril's proposal to add a few lines of code to the numa helper so that it can test the share memory just like the command blow does: `numactl --length=1M --file /dev/shm/numa_shm --interleave=all --touch` And, the orignal test7() has been removed, replaced by a new test for share memory allocated on preferred numa node(see: test3). Signed-off-by: Li Wang <liwang@redhat.com>

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 <jstancek@redhat.com> Acked-by: Cyril Hrubis <chrubis@suse.cz>

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 <jstancek@redhat.com>

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/utrace-devel@redhat.com/msg01944.html Signed-off-by: Jan Stancek <jstancek@redhat.com> Acked-by: Cyril Hrubis <chrubis@suse.cz>

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 <vkabatov@redhat.com>

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 <vkabatov@redhat.com> Signed-off-by: Cyril Hrubis <chrubis@suse.cz>

The test tries to allocate 2 * (half the number of available hugepages). If we have odd number hugepages, the calculated allocation size is not page-aligned and allocation fails. e.g, (use -s option to trigger it manually) $ hugeshmctl02 -s 7 -i 5 hugeshmctl02 0 TINFO : set nr_hugepages to 7 hugeshmctl02 1 TBROK : hugeshmctl02.c:153: shmget #2: errno=ENOMEM(12): Cannot allocate memory hugeshmctl02 2 TBROK : hugeshmctl02.c:153: Remaining cases broken hugeshmctl02 0 TINFO : set nr_hugepages to 0 Align the size to hugepage_size. Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Acked-by: Cyril Hrubis <chrubis@suse.cz>

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 <jstancek@redhat.com> Acked-by: Cyril Hrubis <chrubis@suse.cz>

runltp_ng(ssh): Do not ping before ssh connect

Using system-wide "Cached" size is not accurate. The test is sporadically failing with warning on ppc64le 4.18 and 5.0 kernels. Problem is that test over-estimates max readahead size, which then leads to fewer readhead calls and kernel can silently trim length in each of them: ... readahead02.c:244: INFO: Test #2: POSIX_FADV_WILLNEED on file readahead02.c:134: INFO: creating test file of size: 67108864 readahead02.c:263: INFO: read_testfile(0) readahead02.c:274: INFO: read_testfile(1) readahead02.c:189: INFO: max ra estimate: 12320768 readahead02.c:198: INFO: readahead calls made: 6 readahead02.c:204: PASS: offset is still at 0 as expected readahead02.c:308: INFO: read_testfile(0) took: 492486 usec readahead02.c:309: INFO: read_testfile(1) took: 430627 usec readahead02.c:311: INFO: read_testfile(0) read: 67108864 bytes readahead02.c:313: INFO: read_testfile(1) read: 59244544 bytes readahead02.c:316: PASS: readahead saved some I/O readahead02.c:324: INFO: cache can hold at least: 264192 kB readahead02.c:325: INFO: read_testfile(0) used cache: 124992 kB readahead02.c:326: INFO: read_testfile(1) used cache: 12032 kB readahead02.c:338: WARN: using less cache than expected Try raising bdi readahead limit as much as we can. We write and read back "read_ahead_kb" sysfs value, starting with filesize. If that fails, we try again with lower value. readahead_length used in the test is then set to MIN(bdi limit, 2M), so we respect also kernels prior to commit 600e19afc5f8 ("mm: use only per-device readahead limit"). Signed-off-by: Jan Stancek <jstancek@redhat.com> Reviewed-by: Amir Goldstein <amir73il@gmail.com> Tested-by: Li Wang <liwang@redhat.com>

That returns timestamps that should return values comparable to the stime/rtime/ctime. From Thomas Gleixner: > Due to the internal implementation of ktime_get_real_seconds(), which is > a 2038 safe replacement for the former get_seconds() function, this > accumulation issue can be observed. (time(2) via syscall and newer > versions of VDSO use the same mechanism). > > clock_gettime(CLOCK_REALTIME, &ts); > sec = time(); > assert(sec >= ts.tv_sec); > > That assert can trigger for two reasons: > > 1) Clock was set between the clock_gettime() and time(). > > 2) The clock has advanced far enough that: > > timekeeper.tv_nsec + (clock_now_ns() - last_update_ns) > NSEC_PER_SEC > The same problem exists for CLOCK_XXX vs. CLOCK_XXX_COARSE > > clock_gettime(CLOCK_XXX, &ts); > clock_gettime(CLOCK_XXX_COARSE, &tc); > assert(tc.tv_sec >= ts.tv_sec); > > The _COARSE variants return their associated timekeeper.tv_sec,tv_nsec > pair without reading the clock. Same as #2 above just extended to clock > MONOTONIC. Which means the timestamps in the structure we get from msg* calls can be 1 second smaller that timestamps returned from realtime timers. However it also means that the _COARSE timers should be the same as the SysV timestamps and could be used for these tests instead. Also these timers should be available since 2.6.32 which is old enough to assume that they are present. Signed-off-by: Cyril Hrubis <chrubis@suse.cz> Acked-by: Li Wang <liwang@redhat.com> Acked-by: Jan Stancek <jstancek@redhat.com>

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 <krzysztof.kozlowski@canonical.com> --- 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 <krzysztof.kozlowski@canonical.com> --- 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 <krzysztof.kozlowski@canonical.com>

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 <krzysztof.kozlowski@canonical.com> --- 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 <krzysztof.kozlowski@canonical.com>

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 <jstancek@redhat.com> Acked-by: Petr Vorel <pvorel@suse.cz>

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 <jstancek@redhat.com> Acked-by: Petr Vorel <pvorel@suse.cz> Reviewed-by: Cyril Hrubis <chrubis@suse.cz>

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 <chrubis@suse.cz> Reviewed-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>

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 <pengfei.xu@intel.com> Signed-off-by: Cyril Hrubis <chrubis@suse.cz>

The readahead time-consuming is quit depending on the platform IO speed, test get timeout once the default max_runtime is used up. readahead02.c:223: TINFO: Test #1: readahead on overlayfs file ... readahead02.c:286: TINFO: read_testfile(0) took: 63382903 usec readahead02.c:287: TINFO: read_testfile(1) took: 47943122 usec ... readahead02.c:312: TPASS: using cache as expected readahead02.c:223: TINFO: Test #2: POSIX_FADV_WILLNEED on file readahead02.c:128: TINFO: creating test file of size: 67108864 readahead02.c:241: TINFO: read_testfile(0) Test timeouted, sending SIGKILL! Let's raise the maximum runtime dynamically. Signed-off-by: Li Wang <liwang@redhat.com>

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 <pcervinka@suse.com> Suggested-by: Cyril Hrubis <chrubis@suse.cz> Signed-off-by: Petr Vorel <pvorel@suse.cz>

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/20231012091546.607702-1-pvorel@suse.cz/ Reported-by: Petr Cervinka <pcervinka@suse.com> Suggested-by: Cyril Hrubis <chrubis@suse.cz> Signed-off-by: Petr Vorel <pvorel@suse.cz>

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 <pcervinka@suse.com> Suggested-by: Cyril Hrubis <chrubis@suse.cz> Reviewed-by: Marius Kittler <mkittler@suse.de> Signed-off-by: Petr Vorel <pvorel@suse.cz>

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 <jstancek@redhat.com> Reviewed-by: Cyril Hrubis <chrubis@suse.cz> Reviewed-by: Li Wang <liwang@redhat.com>

Restore corrupted data file

305d0f0

Previous patch to add missing newlines to files modified a file which contains binary data. Signed-off-by: Chris Dearman <chris@mips.com>

gaowanlong added a commit that referenced this pull request Oct 19, 2012

Merge pull request #2 from piet-delaney/fix-dd-file

46ef35d

-Restore corrupted data file

gaowanlong merged commit 46ef35d into linux-test-project:master Oct 19, 2012

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 referenced this pull request in cfconrad/ltp Oct 8, 2018

Merge pull request #2 from cfconrad/runltp-ng_noping

9a19e0a

runltp_ng(ssh): Do not ping before ssh connect

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

yumdeer mentioned this pull request Jan 16, 2020

I can`t find the commit 54a307ba8d3c of fanotify09 #633

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

pevik mentioned this pull request Mar 4, 2024

Rewrite logrotate case with using tst_test.sh #1139

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Restore corrupted data file #2

Restore corrupted data file #2

Uh oh!

chrisdearman commented Oct 19, 2012

Uh oh!

gaowanlong commented Oct 19, 2012

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Restore corrupted data file #2

Restore corrupted data file #2

Uh oh!

Conversation

chrisdearman commented Oct 19, 2012

Uh oh!

gaowanlong commented Oct 19, 2012

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants