From: Petr Vorel <pvorel@suse.cz>
To: Jan Stancek <jstancek@redhat.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 3/5] mq_timedsend01: Workaround segfault on libc variant on 32 bit
Date: Fri, 15 Nov 2024 15:00:05 +0100 [thread overview]
Message-ID: <20241115140005.GD1718754@pevik> (raw)
In-Reply-To: <CAASaF6z3quzaFkgo47SZgpPxK=Ny_2f3C07LR7=8eVFrTa6CfQ@mail.gmail.com>
Hi Jan,
> On Thu, Nov 14, 2024 at 3:40 PM Petr Vorel <pvorel@suse.cz> wrote:
> > EFAULT test segfaults on newer kernels (e.g. 6.4) on libc variant on
> > 32bit. Similarly to 1d4d5a0750 use typical LTP workaround to test by
> > forked child + checking the terminating signal.
...
> > +static void test_bad_addr(unsigned int i)
> > +{
> > + struct time64_variants *tv = &variants[tst_variant];
> > + pid_t pid;
> > + int status;
> > +
> > + pid = SAFE_FORK();
> > + if (!pid) {
> > + verify_mqt_send_receive(i, pid);
> > + _exit(0);
> > + }
> > +
> > + SAFE_WAITPID(pid, &status, 0);
> > +
> > + if (WIFEXITED(status) && !WEXITSTATUS(status))
> > + return;
> > +
> > + if (tv->ts_type == TST_LIBC_TIMESPEC &&
> > + WIFSIGNALED(status) && WTERMSIG(status) == SIGSEGV) {
> > + tst_res(TPASS, "Child killed by expected signal");
> > + return;
> > + }
> > +
> > + tst_res(TFAIL, "Child %s", tst_strstatus(status));
> > +}
> > +
> > +static void do_test(unsigned int i)
> > +{
> > + struct time64_variants *tv = &variants[tst_variant];
> > + const struct test_case *tc = &tcase[i];
> > + unsigned int j;
> > + pid_t pid = -1;
> > +
> > + tst_ts_set_sec(&ts, tc->tv_sec);
> > + tst_ts_set_nsec(&ts, tc->tv_nsec);
> > +
> > + if (tc->bad_ts_addr) {
> Would it make sense to run bad_msg_addr/EFAULT test also in child?
First, thanks a lot a review.
I'm not sure myself. So far it's not needed (problem is only with struct
timespec *abs_timeout not with const char msg_ptr[]). But OTOH it does not
harm. Doing this might prevent some failure in the future.
Kind regards,
Petr
> > + test_bad_addr(i);
> > + return;
> > + }
...
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2024-11-15 14:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-14 14:40 [LTP] [PATCH 0/5] mq_timedsend01: sigtimedwait01: Workaround segfault on libc variant on 32 bit Petr Vorel
2024-11-14 14:40 ` [LTP] [PATCH 1/5] mq_timedsend01: Fix different signedness error on 32bit Petr Vorel
2024-11-14 14:40 ` [LTP] [PATCH 2/5] mq_timedsend01: Remove unneeded designated initializers Petr Vorel
2024-11-14 14:40 ` [LTP] [PATCH 3/5] mq_timedsend01: Workaround segfault on libc variant on 32 bit Petr Vorel
2024-11-15 13:13 ` Jan Stancek
2024-11-15 14:00 ` Petr Vorel [this message]
2024-11-18 9:45 ` Jan Stancek
2024-11-25 9:28 ` Petr Vorel
2024-11-14 14:40 ` [LTP] [PATCH 4/5] libs/sigwait: " Petr Vorel
2024-11-14 14:40 ` [LTP] [PATCH 5/5] libs/sigwait: Use safe/test macros Petr Vorel
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=20241115140005.GD1718754@pevik \
--to=pvorel@suse.cz \
--cc=jstancek@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox