From: Ammar Faizi <[email protected]>
To: Willy Tarreau <[email protected]>
Cc: Shuah Khan <[email protected]>,
"Paul E. McKenney" <[email protected]>,
Gilang Fachrezy <[email protected]>,
Alviro Iskandar Setiawan <[email protected]>,
GNU/Weeb Mailing List <[email protected]>,
Linux Kernel Mailing List <[email protected]>,
Linux Kselftest Mailing List <[email protected]>
Subject: Re: [PATCH v3 0/5] nolibc signal handling support
Date: Sun, 15 Jan 2023 23:01:06 +0700 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On Sun, Jan 08, 2023 at 07:49:30PM +0100, Willy Tarreau wrote:
> On Mon, Jan 09, 2023 at 01:31:17AM +0700, Ammar Faizi wrote:
> > I'll be pondering this code this week (to follow what actually the
> > rt_sigaction wants on i386 and arm):
> >
> > https://github.com/torvalds/linux/blob/v6.2-rc3/kernel/signal.c#L4404-L4434
>
> Seems like it could simply be a matter of sigsetsize, which is the
> first one returning -EINVAL.
>
> > Hopefully, I can get it sorted before the weekend.
>
> OK!
I couldn't dedicate much time to this, but I looked into it, and here's
my report on the progress. I didn't manage to find a proper solution to
this. But yes, you're right. It's a matter of 'sizeof(sigset_t)'.
So here is my observation. Currently, nolibc's sys.h includes this:
#include <asm/signal.h>
The definition of 'sigset_t' in that header is:
typedef unsigned long sigset_t;
On i386, 'sizeof(unsigned long)' is 4, but on x86-64 it's 8.
That is not the 'sigset_t' that the kernel wants. The kernel wants the
'sigset_t' that is in <asm-generic/signal.h>:
#define _NSIG 64
#define _NSIG_BPW __BITS_PER_LONG // this 64 on x86-64, but 32 on i386.
#define _NSIG_WORDS (_NSIG / _NSIG_BPW)
typedef struct {
unsigned long sig[_NSIG_WORDS];
} sigset_t;
The above struct is always 8 bytes in size. In other words:
_NSIG_WORDS == 2 on i386
_NSIG_WORDS == 1 on x86-64
sizeof(unsigned long) == 4 on i386
sizeof(unsigned long) == 8 on x86-64
Therefore, sizeof(unsigned long [_NSIG_WORDS]) is always 8 on both
architectures. That's the correct size.
I tried to #include <asm-generic/signal.h> but it conflicts with the
other 'sigset_t' definition. So I can't do that.
Why are there two different definitions of 'sigset_t'? I don't know.
I probably should read the story behind this syscall to get it
implemented right. Let me ponder this again on Monday. But at least I
tell what I have found so people can give some comments on it...
--
Ammar Faizi
next prev parent reply other threads:[~2023-01-15 16:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-08 13:58 [PATCH v3 0/5] nolibc signal handling support Ammar Faizi
2023-01-08 13:59 ` [PATCH v3 1/5] nolibc/sys: Implement `sigaction(2)` function Ammar Faizi
2023-01-08 13:59 ` [PATCH v3 2/5] nolibc/sys: Implement `signal(2)` function Ammar Faizi
2023-01-08 13:59 ` [PATCH v3 3/5] selftests/nolibc: Add `fork(2)` selftest Ammar Faizi
2023-01-08 13:59 ` [PATCH v3 4/5] selftests/nolibc: Add `sigaction(2)` selftest Ammar Faizi
2023-01-08 13:59 ` [PATCH v3 5/5] selftests/nolibc: Add `signal(2)` selftest Ammar Faizi
2023-01-08 17:58 ` [PATCH v3 0/5] nolibc signal handling support Willy Tarreau
2023-01-08 18:31 ` Ammar Faizi
2023-01-08 18:49 ` Willy Tarreau
2023-01-15 16:01 ` Ammar Faizi [this message]
2023-01-15 17:06 ` Alviro Iskandar Setiawan
2023-01-17 23:17 ` Ammar Faizi
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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