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

[H.J. Lu]

On Wed, Nov 18, 2020 at 9:35 AM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * Dave Martin:
>
> > Having _GNU_SOURCE enable this feature will break existing source code.
>
> Does this matter?
>
> The code is already broken on a quickly increasing number of machines,
> so it needs fixing anyway.  A compile-time error is probably
> preferable to an obscure run-time failure.

I can see points on both sides.  Either approach is better than the status quo.
Can we make a decision for glibc 2.33?

> > It probably should go under _GNU_SOURCE in the long term, but is there
> > usually a transitional period when the change is opt-in via some feature
> > macro?
>
> Not always.  See the iszero and other macros in <math.h>, that also
> broke existing sources (largely C++, so we worked around it by using
> C++ features instead of macros).  There are also many older examples.
>
> > 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.
>
> But this is somewhat separate from fixing stack sizes to accomodate
> kernel and hardware needs.
>
> By the way, something that I tried to raise in the past, but wasn't
> good at it: In the future, we may need a mechanism to reduce the
> kernel stack size usage for legacy binaries, perhaps using
> virtualization.  The last time I looked at this, the signal context
> did not actually reduce when AVX-512 support was masked in a guest, I
> think.  (Okay, this is largely for H.J.'s benefit.)  This also applies
> to ld.so and its context save operation.  Fortunately, not many people
> have run into this compatibility issue so far.  The case I remember
> was an application that broke because it assumed zeros on the stack,
> and the XSAVE trampoline wrote some non-zero bits there because it
> reached much deeper into the stack.  But the user was happy when we
> found the root cause and was able to add the missing initializer to
> their code, so all was good.

We, Intel, are investigating different approaches to improve signal handling
on machines with large XSAVE states.  One possibility is fast signal handler
where the programmer informs the kernel that only to save and restore a subset
of XSAVE states in the signal handler and update the compiler to enforce that.


-- 
H.J.