PING: V7 [PATCH] sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305]

[Dave Martin]

On Thu, Nov 19, 2020 at 11:16:57AM -0500, Rich Felker wrote:
> 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
> > <libc-alpha@sourceware.org> 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.

I'd also thought about this, and I feel it does mostly work on systems
with atomic read-modify-writes of some sort, but there are a lot of
tricky details.

We might be able to move a lot of the "legacy" signal delivery logic to
userspace, eliminating all kernel entries except for asynchronous signal
delivery that comes out of the blue.

My instinct says that it would be better to have a more stripped down
kernel signal delivery mechanism that is actually designed as a
foundation for this.  Then all the "legacy" signal delivery logic could
be implemented in userspace.

POSIX signals are trying to meet a bunch of mutually defeating goals,
some of them historic and quite misguided -- so they're never going to
be all that satisfactory as a base to build on.

> 
> > (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.

I see.  I might still try to hack up a better ucontext interface if
(heh) I find myself with time on my hands, but I won't cite your needs
as a use case!

Cheers