From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 6119 invoked from network); 29 Oct 2020 13:51:59 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 29 Oct 2020 13:51:59 -0000
Received: (qmail 14324 invoked by uid 550); 29 Oct 2020 13:51:56 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 14306 invoked from network); 29 Oct 2020 13:51:56 -0000
Date: Thu, 29 Oct 2020 16:51:44 +0300 (MSK)
From: Alexander Monakov <amonakov@ispras.ru>
To: musl@lists.openwall.com
In-Reply-To: <20201029133839.GL534@brightrain.aerifal.cx>
Message-ID: <alpine.LNX.2.20.13.2010291649450.2454@monopod.intra.ispras.ru>
References: <20201029063448.GK534@brightrain.aerifal.cx> <b215b5cf68dfefc5b35e41900b5bafef@ispras.ru> <20201029133839.GL534@brightrain.aerifal.cx>
User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Subject: Re: [musl] 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