All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Schmaus via ltp <ltp@lists.linux.it>
To: Petr Vorel <pvorel@suse.cz>
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:06:52 +0200	[thread overview]
Message-ID: <614059f8-983e-4f29-a730-3e0ceb541b9f@codasip.com> (raw)
In-Reply-To: <20250808140435.GB470368@pevik>

On 08/08/2025 16.04, Petr Vorel wrote:
> Hi Florian,

Hi Petr,

thanks for your review.

>> 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.


> 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.


> 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.

- Florian




-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2025-08-08 16:07 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 [this message]
2025-08-08 16:45     ` 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=614059f8-983e-4f29-a730-3e0ceb541b9f@codasip.com \
    --to=ltp@lists.linux.it \
    --cc=florian.schmaus@codasip.com \
    --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 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.