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

[Szabolcs Nagy]

The 11/18/2020 18:09, Dave Martin via Libc-alpha wrote:
> On Wed, Nov 18, 2020 at 06:35:00PM +0100, Florian Weimer wrote:
> > * Dave Martin:
> > > I have some thoughts on what a better interface might look like --
> > > basically separating the signal ucontext_t type from the setcontext()/
> > > getcontext() etc. type, and providing accessors for the architectural
> > > register state rather than just having a fixed struct definition for
> > > mcontext_t.
> > >
> > > But, there also may not be a lot of appetite for such a change, and
> > > I can't see how it could be backwards compatible.
> > >
> > > I can elaborate if people think it's worth discussing.
> > 
> > I think Rich Felker wants to copy signal contexts around to implement
> > critical sections that can't be interrupted by a signal handler, I
> > think that would need this fully fixed.
> 
> Is rseq a more suitable way to do that sort of thing on new-ish Linux?
> I guess a fallback may be needed for older / other kernels though.

rseq does not help with libc critical sections:

the point is not to restart the critical section
(which would require no side effect or mechanisms
to roll side effects back and that the section is
entirely written in asm between begin/end labels
so the kernel knows when the section is left),

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. such solution allows hiding all libc
internal inconsistent state from user code so async
signal handlers can call all libc apis.

> For aarch64 an explicit prctl()/sysctl opt-in is needed to enable jumbo
> vector registers before you see oversized signal frames, though I don't
> think there is a similar control for AVX-512.
> 
> Even on aarch64, this interface is not very friendly though.  It might
> be better to have some ELF attribute that ld.so or the libc startup can
> arbitrate on and twiddle the appropriate switches.

we can probably mark binaries if they are large
vector length compatible. (but the incompatible
binaries have to be hunted down manually and all
we can do with them at dlopen time is to give a
nice dlerror in case the vlengh got increased)