[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 29 Oct 2020 17:18:20 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: More thoughts on wrapping signal handling
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.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
