mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [musl] More thoughts on wrapping signal handling
Date: Thu, 29 Oct 2020 10:28:23 -0400	[thread overview]
Message-ID: <20201029142823.GN534@brightrain.aerifal.cx> (raw)
In-Reply-To: <alpine.LNX.2.20.13.2010291714030.2454@monopod.intra.ispras.ru>

On Thu, Oct 29, 2020 at 05:18:20PM +0300, Alexander Monakov wrote:
> On Thu, 29 Oct 2020, Florian Weimer wrote:
> 
> > * Alexander Monakov:
> > 
> > > On Thu, 29 Oct 2020, Alexander Monakov wrote:
> > >
> > >> On Thu, 29 Oct 2020, Rich Felker wrote:
> > >> 
> > >> > Yes, I kinda hand-waved over this with the word "call", which I
> > >> > thought about annotating with (*). In the case of SA_ONSTACK you need
> > >> > a primitive to "call on new stack", and while the ucontext is mostly
> > >> > not meaningful/inspectable to the signal handler (because it's
> > >> > interrupting libc code), the saved signal mask is. You can have the
> > >> > caller restore it (in place of SYS_[rt_]sigreturn), but the natural
> > >> > common solution to all of these needs is having a sort of makecontext.
> > >> 
> > >> Alternatively you could re-raise the signal to have the kernel re-deliver
> > >> it with the correctly regenerated ucontext (and on the right stack)?
> > >> Would that be undesirable for some reason?
> > >
> > > Ah, because there's no way to propagate siginfo struct. Sorry :)
> > 
> > Yes, and that's why I think copying it into TLS space will not work,
> > either.
> 
> Actually I regret rushing that email: clearly as we are talking about wrapped
> signal handlers, re-raising would call the wrapper, which would be perfectly
> capable of substituting saved siginfo.
> 
> So I don't think propagating siginfo is more complicated with this re-raising
> approach.

The reraising is problematic because of how it works with signal
queueing and additional pending signals, I think. You might be able to
make that transparent but I think it's at least slightly nontrivial,
even just figuring out what to do to get them handled in the right
order if there's already another signal pending when you want to
re-raise. If you just unblock and try to handle both from the same
kernel-invoked signal handler, you'll miss the second if the first one
doesn't return normally. And if you try to re-raise to get the second
one, you just push back the issue again, possibly arbitrarily many
times. Maybe this works but it seems messy...

Rich

  reply	other threads:[~2020-10-29 14:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-29  6:34 Rich Felker
2020-10-29 11:45 ` Alexey Izbyshev
2020-10-29 13:38   ` Rich Felker
2020-10-29 13:51     ` Alexander Monakov
2020-10-29 14:02       ` Alexander Monakov
2020-10-29 14:12         ` Florian Weimer
2020-10-29 14:18           ` Alexander Monakov
2020-10-29 14:28             ` Rich Felker [this message]
2020-10-31 17:33     ` Alexey Izbyshev
2020-10-29 14:21 ` Szabolcs Nagy
2020-10-29 14:43   ` Rich Felker

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=20201029142823.GN534@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).