From: Petr Vorel <pvorel@suse.cz>
To: Florian Schmaus <florian.schmaus@codasip.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] sigrelse01: Check if signal 34 is available for musl compat
Date: Fri, 8 Aug 2025 18:45:37 +0200 [thread overview]
Message-ID: <20250808164537.GB485362@pevik> (raw)
In-Reply-To: <614059f8-983e-4f29-a730-3e0ceb541b9f@codasip.com>
Hi Florian,
> On 08/08/2025 16.04, Petr Vorel wrote:
> > Hi Florian,
> Hi Petr,
> thanks for your review.
yw, thanks for your work on LTP for musl.
> > > Do not select signal 34 when the test is run using musl. Signal 34 is
> > > used internally by musl as SIGSYNCCALL. Consequently, musl's signal()
> > > will return with an error status and errno set to EINVAL when trying
> > > to setup a signal handler for signal 34, causing the sigrelse01 test
> > > to fail.
> > > Since musl provides no preprocessor macro, we check for the
> > > availability of signal 34 by attempting to setup a signal handler. If
> > > signal() returns SIG_ERR with errno set to EINVAL then we assume the
> > > signal is unavailable. Knowing signal 34 is available with glibc, we
> > > perform this check only if __GLIBC__ is not defined.
> > ...
> > > +++ b/testcases/kernel/syscalls/sigrelse/sigrelse01.c
> > > +#define _GNU_SOURCE
> > Unfortunately +#define _GNU_SOURCE causes test to hang, at least on glibc.
> I don't think it hangs, but takes ages to complete. At least, that is what I
> found.
Yeah, you're more precise :). Nevertheless the result for the patchset remains
=> NACK when runtime drastically changes like this :(.
> > And I see for musl it is necessary to get sighandler_t.
> > Until you fix glibc with _GNU_SOURCE NACK.
> I think I can get rid of the _GNU_SOURCE. IIRC it was just needed to use the
> sighandler_t type. Without _GNU_SOURCE, declaring the return value of
> signal() as void* should also work.
I suspect there is something else going wrong (test should not start magically
using sighold() on glibc), but let's try a workaround.
> > But on glibc it also brought a warning, which means _GNU_SOURCE really switches
> > something on:
> > sigrelse01.c: In function ‘child’:
> > sigrelse01.c:397:33: warning: ‘sighold’ is deprecated: Use the sigprocmask function instead [-Wdeprecated-declarations]
> > 397 | if ((rv = sighold(sig)) != 0) {
> > | ^~
> > In file included from /usr/include/sys/wait.h:36,
> > from sigrelse01.c:104:
> > /usr/include/signal.h:355:12: note: declared here
> > 355 | extern int sighold (int __sig) __THROW
> > | ^~~~~~~
> > sigrelse01.c:472:25: warning: ‘sigrelse’ is deprecated: Use the sigprocmask function instead [-Wdeprecated-declarations]
> > 472 | if ((rv = sigrelse(sig)) != 0) {
> > | ^~
> > /usr/include/signal.h:359:12: note: declared here
> > 359 | extern int sigrelse (int __sig) __THROW
> > | ^~~~~~~~
> > sigrelse01.c: In function ‘timeout’:
> > sigrelse01.c:675:25: warning: unused parameter ‘sig’ [-Wunused-parameter]
> > 675 | static void timeout(int sig)
> > | ~~~~^~~
> > Also this is a very old test, which needs cleanup and rewrite to new LTP API
> > (e.g. remove old unixes, e.g. VAX and get test more reliable). I suppose
> > handling signals with LTP legacy API is broken.
> > > +
> > > #include <sys/types.h>
> > > #include <sys/wait.h>
> > > #include <errno.h>
> > > #include <fcntl.h>
> > > #include <signal.h>
> > > +#include <stdbool.h>
> > nit: I would postpone this after conversion this to new LTP API.
> > Script already uses legacy definitions
> > #define TRUE 1
> > #define FALSE 0
> > and on a different place happily returns 0 or 1.
> > Mixing that with <stdbool.h> makes even more mess.
> Agreed.
> I am going send a v2 that does not use _GNU_SOURCE nor stdbool.h after
> checking that it still fixes musl compat for us while not introducing a
> regression on glibc.
+1, please document the reason for a workaround.
If you had more time, the best would be to rewrite the test to the new LTP API.
I bet the problem with _GNU_SOURCE would go away. I don't expect you have more
time, but if you do, here are links:
https://github.com/linux-test-project/ltp/blob/master/doc/old/C-Test-API.asciidoc
https://linux-test-project.readthedocs.io/en/latest/developers/api_c_tests.html
https://linux-test-project.readthedocs.io/en/latest/developers/test_case_tutorial.html
(We are in the middle of a doc transition into readthedocs, IMHO the old doc is
still the best what we have.)
Also, 3 tests even don't compile on musl, here is the current list:
https://github.com/linux-test-project/ltp/blob/master/ci/alpine.sh#L32
Helping to fix them is more than welcome.
Kind regards,
Petr
> - Florian
--
Mailing list info: https://lists.linux.it/listinfo/ltp
prev parent reply other threads:[~2025-08-08 16:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-31 6:57 [LTP] [PATCH] sigrelse01: Check if signal 34 is available for musl compat Florian Schmaus via ltp
2025-08-08 14:04 ` Petr Vorel
2025-08-08 16:06 ` Florian Schmaus via ltp
2025-08-08 16:45 ` Petr Vorel [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=20250808164537.GB485362@pevik \
--to=pvorel@suse.cz \
--cc=florian.schmaus@codasip.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 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.