public inbox for [email protected]
 help / color / mirror / Atom feed
From: Willy Tarreau <[email protected]>
To: Ammar Faizi <[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, 8 Jan 2023 19:49:30 +0100	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On Mon, Jan 09, 2023 at 01:31:17AM +0700, Ammar Faizi wrote:
> >   - riscv and mips build are now broken:
> >       sysroot/riscv/include/sys.h:1110:18: error: 'struct sigaction' has no member named 'sa_restorer'
> >        1110 |         if (!act2.sa_restorer) {
> >             |                  ^
> >       sysroot/riscv/include/sys.h:1111:34: error: 'SA_RESTORER' undeclared (first use in this function); did you mean 'SA_RESTART'?
> >        1111 |                 act2.sa_flags |= SA_RESTORER;
> >             |                                  ^~~~~~~~~~~
> >             |                                  SA_RESTART
> 
> Just a speculation:
> This is probably because not all architectures have a SA_RESTORER. I'll
> need to figure out how Linux handles signal on those architectures.

Yes that's the case, there's even some ifdef around it in the generic
code. I have no idea how it works there, at least it seems worth having
a look to make sure we don't miss something easy.

> >   - s390 segfaults:
> >       58 select_fault = -1 EFAULT              [OK]
> >       59 sigactionqemu: uncaught target signal 11 (Segmentation fault) - core dumped
> >       Segmentation fault
> > 
> >     It dies in __restore_rt at 1006ba4 while performing the syscall,
> >     I don't know why, maybe this arch requires an alt stack or whatever :
> > 
> >       0000000001006ba0 <__restore_rt>:
> >        1006ba0:       a7 19 00 ad             lghi    %r1,173
> >        1006ba4:       0a 00                   svc     0
> >        1006ba6:       07 07                   nopr    %r7
> 
> Bah, no clue on this. I'll CC s390 people in the next version and ask
> them to shed some light.

OK.

> 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 also think that the printf() in test_sigaction_sig() are not welcome
> > as they corrupt the output. Maybe one thing you could do to preserve the
> > info would be to prepend a space in front of the message and remove the
> > LF. For example the simple patch below:
> [...]
> > Which is way more readable and still grep-friendly.
> 
> Yeah, that looks much better. Applied to my local git tree with
> attribution.

Don't worry with attribution for such patches from me. I'd rather see
the first patch looking good at once than having an extra one change
the output just for the sake of attribution! It was just a suggestion
anyway and whatever solution you find that improves the output will be
fine.

Thank you!
Willy

  reply	other threads:[~2023-01-08 18:49 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 [this message]
2023-01-15 16:01       ` Ammar Faizi
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