From: Petr Vorel <pvorel@suse.cz>
To: Teo Couprie Diaz <teo.coupriediaz@arm.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [RFC PATCH 0/1] brk: use direct syscalls
Date: Mon, 28 Nov 2022 20:30:26 +0100 [thread overview]
Message-ID: <Y4UMUqkLijWXOWu6@pevik> (raw)
In-Reply-To: <20221128091508.75414-1-teo.coupriediaz@arm.com>
> Hello LTP maintainers,
> This patch slightly reworks the brk01 and brk02 tests to use direct
> syscalls with tst_syscall rather than calling through the libc.
> While running LTP on a musl-based distribution, we noticed that the brk
> tests were failing. It turns out that Musl prevents the use of brk
> with their wrapper: it always returns an error.
> This isn't too egregious as using brk is deprecated in favor of malloc
> and it isn't part of POSIX anymore since POSIX.1-2001, but it _is_
> different from glibc's beavior, which allows using it.
> This patch allows proper testing of brk's functionality, independent of
> libc specifics, and thus allows the tests to pass on Musl-based
> distributions like Alpine.
> Do you think this is a correct approach for LTP ?
> From what I could see there are a few tests that use tst_syscall directly
> and it doesn't affect the logic much for brk.
LGTM.
I wonder if it makes sense to add .test_variants [1] for glibc and uclibc,
e.g. for brk01():
void verify_brk(void)
{
if (tst_variant) {
tst_res(TINFO, "Testing sbrk()");
cur_brk = (uintptr_t)sbrk(0);
} else {
tst_res(TINFO, "Testing __NR_brk");
cur_brk = (void *)tst_syscall(__NR_brk, 0);
}
}
struct tst_test test = {
...
#ifdef __GLIBC__
.test_variants = 2,
#else
.test_variants = 1,
#endif
...
Not sure if it should be testeed also on android, i.e:
#if defined(__GLIBC__) || defined(__ANDROID__)
Kind regards,
Petr
[1] https://github.com/linux-test-project/ltp/wiki/C-Test-API#130-testing-similar-syscalls-in-one-test
> Green build:
> https://github.com/Teo-CD/ltp/actions/runs/3563193507
> This was discovered in the context of the Morello project[0].
> [0]: https://www.morello-project.org/
> Teo Couprie Diaz (1):
> syscalls/brk: use direct syscall
> testcases/kernel/syscalls/brk/brk01.c | 15 ++++++---------
> testcases/kernel/syscalls/brk/brk02.c | 14 ++++++--------
> 2 files changed, 12 insertions(+), 17 deletions(-)
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-11-28 19:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-28 9:15 [LTP] [RFC PATCH 0/1] brk: use direct syscalls Teo Couprie Diaz
2022-11-28 9:15 ` [LTP] [RFC PATCH 1/1] syscalls/brk: use direct syscall Teo Couprie Diaz
2022-11-28 19:30 ` Petr Vorel [this message]
2022-11-29 13:09 ` [LTP] [RFC PATCH 0/1] brk: use direct syscalls Cyril Hrubis
2022-11-29 13:36 ` Petr Vorel
2022-11-29 13:40 ` Cyril Hrubis
2022-11-30 13:03 ` Teo Couprie Diaz
2022-11-30 13:15 ` Cyril Hrubis
2022-11-30 14:22 ` Teo Couprie Diaz
2022-11-30 12:49 ` Teo Couprie Diaz
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=Y4UMUqkLijWXOWu6@pevik \
--to=pvorel@suse.cz \
--cc=ltp@lists.linux.it \
--cc=teo.coupriediaz@arm.com \
/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.