From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id AB095398E451 for ; Thu, 19 Nov 2020 16:16:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AB095398E451 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dalias@libc.org Date: Thu, 19 Nov 2020 11:16:57 -0500 From: Rich Felker To: Zack Weinberg Cc: Szabolcs Nagy , Dave Martin , Florian Weimer , "H.J. Lu via Libc-alpha" , Joseph Myers Subject: Re: PING: V7 [PATCH] sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305] Message-ID: <20201119161657.GG534@brightrain.aerifal.cx> References: <87lfeyvghf.fsf@mid.deneb.enyo.de> <20201118170434.GF6882@arm.com> <873616va9n.fsf@mid.deneb.enyo.de> <20201118180927.GI6882@arm.com> <20201119145934.GC20578@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 16:17:00 -0000 On Thu, Nov 19, 2020 at 10:39:47AM -0500, Zack Weinberg wrote: > On Thu, Nov 19, 2020 at 10:00 AM Szabolcs Nagy via Libc-alpha > wrote: > .... > > but to let the critical section with all its side > > effects complete and delay the signal handler > > until then. (the slow and easy way to do this is > > masking signals using syscalls around critical > > sections, a fast solution needs signal wrapping > > and saving the sigcontext.) > > > > for example the entire malloc call can be a critical > > section and an incomming signal delayed until malloc > > completes. > > I read this and I'm wondering how impractical it would be to invent a > way to perform pthread_sigmask() operations without a system call. > > Abstractly, the signal mask for each thread _could_ be placed in user > space at an ABI-specified location where the kernel can find it I've worked this out before, and it's mostly simple, but might have some corner cases. Archs without an atomic (in single threaded sense) 64-bit (128-bit for MIPS) store operation can't update the mask without tearing (a signal arriving between the partial writes could see an inconsistent signal mask), so they couldn't use a naive form. Having two slots you can alternate between (update the inactive one then write the selector to switch which one is active) should work though. There are probably lots of other minor issues like this but I think they're all solveable. > (bottom of the thread stack, maybe, or an offset from the TLS base); > this doesn't make anything new possible (the kernel will just continue > to ignore the bits for SIGKILL, SIGSEGV, etc.) so it wouldn't be a > privilege violation. It could either be managed by the vdso, or at an address registered by a syscall (similar to robust_list) rather than some hard-coded contract. But in any case, even if this were added, it wouldn't meet the needs for use case I proposed in musl. It doesn't solve the execve race with abort (and can't, since it's just equivalent to optimizing signal blocking we can already do, not introducing any new capability) and it would not be available on past kernels, only future ones. > Seems like that would be much easier than copying sigcontexts around, > and less likely to break code that thinks it knows stuff about signal > frames. You don't need copy sigcontexts around. That's a misunderstanding of how this works. It's just the siginfo that needs to be saved until the deferred handler runs. The sigcontext passed to the handler is then the synchronous context at the time it runs (which becomes the logical time of signal delivery), not the earlier async context, and can thereby be pretty much entirely uninitialized except for return address and stack pointer. Everything else is a representation of internal state from a libc function and can just be all zeros or whatever. Rich