Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 29 Oct 2020 17:02:26 +0300 (MSK)
From: Alexander Monakov <>
Subject: Re: More thoughts on wrapping signal handling

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 :)


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.