From: Teo Couprie Diaz <teo.coupriediaz@arm.com>
To: Petr Vorel <pvorel@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] syscalls/brk: add direct syscall tst_variant
Date: Tue, 6 Dec 2022 14:45:44 +0000 [thread overview]
Message-ID: <fe1c5bac-0ed1-92ef-3c28-e3758dc3465d@arm.com> (raw)
In-Reply-To: <20221206140421.GB21839@pevik>
Hi Petr,
On 06/12/2022 14:04, Petr Vorel wrote:
> Hi Teo,
>
>> Direct usage of brk is discouraged in favor of using malloc. Also, brk was
>> removed from POSIX in POSIX.1-2001.
>> In particular, the Musl libc's brk always returns -ENOMEM which causes
>> the LTP tests to exit prematurely. Invoking the syscall directly allows
>> them to properly validate brk behavior. Add a new test variant handling if
>> the libc wrappers are not implemented and testing the direct syscall.
>> Use tst_syscall() and handle the failure cases ourselves, as
>> we don't depend on the libc to do it anymore.
>> The patch also works around the dependency on sbrk to get the current break
>> as it has the same issues. Instead, call tst_syscall(__NR_brk, 0) which
>> always returns the current break.
>> Update brk01 to use void* to unify it with brk02.
> That brought warnings, see below.
>
> ...
>> +++ b/testcases/kernel/syscalls/brk/brk02.c
>> @@ -14,24 +14,51 @@
>> #include <unistd.h>
>> #include <sys/mman.h>
>> #include "tst_test.h"
>> +#include "lapi/syscalls.h"
>> +
>> +inline void *brk_variants(void *addr)
>> +{
>> + void *brk_addr;
>> + if (tst_variant) {
>> + brk_addr = (void *)tst_syscall(__NR_brk, addr);
>> + } else {
>> + brk_addr = (void *)brk(addr);
> NOTE using pointer for brk() is problematic, there are complains:
>
> brk02.c: In function ‘brk_variants’:
> brk02.c:26:28: warning: cast to pointer from integer of different size
> [-Wint-to-pointer-cast]
> 26 | brk_addr = (void *)brk(addr);
> | ^
>
> Not sure how to fix this. Problem is in both C files, on several places.
Ah yes, of course. That's my mistake: I just realized that I used the
libc brk as if it returned the break, but it doesn't. It just returns an
error, so the warning is justified (and a drowned in other messages from
my build system).
I'll rework and change that, I believe it will work without warnings
once it is properly used.
> There are also code style problems (you can see it when running make check in
> testcases/kernel/syscalls/brk/), but that's a minor detail.
I wasn't aware of that, good to know thanks ! I will take care of it as
well.
> Kind regards,
> Petr
Thanks for giving it a look,
Téo
--
Mailing list info: https://lists.linux.it/listinfo/ltp
prev parent reply other threads:[~2022-12-06 14:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-06 12:26 [LTP] [PATCH] syscalls/brk: add direct syscall tst_variant Teo Couprie Diaz
2022-12-06 14:04 ` Petr Vorel
2022-12-06 14:45 ` Teo Couprie Diaz [this message]
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=fe1c5bac-0ed1-92ef-3c28-e3758dc3465d@arm.com \
--to=teo.coupriediaz@arm.com \
--cc=ltp@lists.linux.it \
--cc=pvorel@suse.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).