From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 5/5] mem/vma05.sh: Convert to the new shell library
Date: Wed, 11 Dec 2024 00:54:36 +0100 [thread overview]
Message-ID: <20241210235436.GC386508@pevik> (raw)
In-Reply-To: <20241203151530.16882-6-chrubis@suse.cz>
Hi Cyril,
> +# env
> +# {
> +# "needs_root": true,
> +# "needs_tmpdir": true,
> +# "needs_cmds": ["gdb"],
Maybe to add here also "uname" ?
> +# "save_restore": [
> +# ["/proc/sys/kernel/core_pattern", "TBROK"],
> +# ["/proc/sys/kernel/core_uses_pid", "TBROK"]
> +# ],
> +# "tags": [
> +# ["linux-git", "103efcd9aac1"],
> +# ["linux-git", "b6558c4a2378"],
> +# ["linux-git", "e5b97dde514f"]
> +# ]
> +# }
> +# ---
...
> -vma_report_check()
> -{
> - if [ $(uname -m) = "x86_64" ]; then
> - if LINE=$(grep "vsyscall" /proc/self/maps); then
> - RIGHT="ffffffffff600000-ffffffffff601000[[:space:]][r-]-xp"
> - if echo "$LINE" | grep -q "$RIGHT"; then
> - tst_res TPASS "[vsyscall] reported correctly"
> - else
> - tst_res TFAIL "[vsyscall] reporting wrong"
> - fi
> +if [ $(uname -m) = "x86_64" ]; then
> + if LINE=$(grep "vsyscall" /proc/self/maps); then
> + RIGHT="ffffffffff600000-ffffffffff601000[[:space:]][r-]-xp"
> + if echo "$LINE" | grep -q "$RIGHT"; then
> + tst_res TPASS "[vsyscall] reported correctly"
> + else
> + tst_res TFAIL "[vsyscall] reporting wrong"
> fi
> fi
> +fi
> - rm -rf core*
> - { vma05_vdso; } > /dev/null 2>&1
> - [ -f core ] || tst_brk TBROK "missing core file"
> +rm -rf core*
> +{ vma05_vdso; } > /dev/null 2>&1
> +[ -f core ] || tst_brk TBROK "missing core file"
Test timeouts for me:
# PATH=.:~/ltp.git/testcases/lib/:$PATH vma05.sh
tst_tmpdir.c:316: TINFO: Using /tmp/LTP_vmaN8CQtx as tmpdir (tmpfs filesystem)
tst_test.c:1890: TINFO: LTP version: 20240930-113-gffde06520
tst_test.c:1894: TINFO: Tested kernel: 6.13.0-rc1-1.g492f944-default #1 SMP PREEMPT_DYNAMIC Mon Dec 2 08:55:00 UTC 2024 (492f944) x86_64
tst_test.c:1725: TINFO: Timeout per run is 0h 00m 30s
vma05.sh:57: TPASS: [vsyscall] reported correctly
Test timeouted, sending SIGKILL!
tst_test.c:1775: TINFO: Killed the leftover descendant processes
tst_test.c:1781: TINFO: If you are running on slow machine, try exporting LTP_TIMEOUT_MUL > 1
tst_test.c:1783: TBROK: Test killed! (timeout?)
HINT: You _MAY_ be missing kernel fixes:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=103efcd9aac1
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b6558c4a2378
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e5b97dde514f
Summary:
passed 1
failed 0
broken 1
skipped 0
warnings 0
But it fails on master, therefore problem on the system I test. Although on
master it was more obvious that the problem is due core dump file not being
created. In new version it just timeouts.
PATH=.:~/ltp.git/testcases/lib/:$PATH LTPROOT=$LTPROOT vma05.sh
vma05 1 TINFO: Running: vma05.sh
vma05 1 TINFO: Tested kernel: Linux ts 6.13.0-rc1-1.g492f944-default #1 SMP PREEMPT_DYNAMIC Mon Dec 2 08:55:00 UTC 2024 (492f944) x86_64 x86_64 x86_64 GNU/Linux
vma05 1 TINFO: Using /tmp/LTP_vma05.I8VXfhyFt6 as tmpdir (tmpfs filesystem)
vma05 1 TINFO: timeout per run is 0h 5m 0s
vma05 1 TPASS: [vsyscall] reported correctly
vma05 1 TBROK: missing core file
vma05 1 TINFO: AppArmor enabled, this may affect test results
vma05 1 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root)
vma05 1 TINFO: loaded AppArmor profiles: none
Summary:
passed 1
failed 0
broken 1
skipped 0
warnings 0
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2024-12-10 23:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-03 15:15 [LTP] [PATCH 0/5] First new shell library converted test Cyril Hrubis
2024-12-03 15:15 ` [LTP] [PATCH 1/5] tst_run_shell: Add save_restore parser Cyril Hrubis
2024-12-10 23:39 ` Petr Vorel
2024-12-03 15:15 ` [LTP] [PATCH 2/5] libs/ujson: Fix "Garbage after JSON string!" in strict mode Cyril Hrubis
2024-12-16 12:33 ` Petr Vorel
2024-12-03 15:15 ` [LTP] [PATCH 3/5] tst_run_shell: Better errors for metadata extractor Cyril Hrubis
2024-12-10 23:56 ` Petr Vorel
2024-12-03 15:15 ` [LTP] [PATCH 4/5] lib/tst_res_.c: Add TBROK handler + more verbose errors Cyril Hrubis
2024-12-11 0:11 ` Petr Vorel
2024-12-11 9:52 ` Cyril Hrubis
2024-12-11 19:36 ` Petr Vorel
2024-12-12 9:03 ` Cyril Hrubis
2024-12-03 15:15 ` [LTP] [PATCH 5/5] mem/vma05.sh: Convert to the new shell library Cyril Hrubis
2024-12-04 7:17 ` Andrea Cervesato via ltp
2024-12-04 7:17 ` Andrea Cervesato via ltp
2024-12-04 7:56 ` Cyril Hrubis
2024-12-10 23:34 ` Petr Vorel
2024-12-16 17:16 ` Cyril Hrubis
2024-12-10 23:54 ` Petr Vorel [this message]
2024-12-11 9:45 ` [LTP] [PATCH 0/5] First new shell library converted test Andrea Cervesato via ltp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241210235436.GC386508@pevik \
--to=pvorel@suse.cz \
--cc=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.