[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.20.13.2010291649450.2454@monopod.intra.ispras.ru>
Date: Thu, 29 Oct 2020 16:51:44 +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, 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?
(apart from extra kernel roundtrip in the (rare) event that original signal
interrupted a critical section)
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.
