[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87pn51ruii.fsf@oldenburg2.str.redhat.com>
Date: Thu, 29 Oct 2020 15:12:21 +0100
From: Florian Weimer <fweimer@...hat.com>
To: musl@...ts.openwall.com
Subject: Re: More thoughts on wrapping signal handling
* 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.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
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.
