The following snippet illustrates request by an extension to use AMX registers:

```
// no increase sigaltstack size fix will not wark till we fix python
void enable_amx_no_fix()
{

    unsigned long bitmask;
    long rc;

    rc = syscall(SYS_arch_prctl, ARCH_REQ_XCOMP_PERM, XFEATURE_XTILEDATA);
    if (rc) {
        printf("The kernel rejects the AMX use.\n");
        printf("errno %d\n",errno);
    } else {
        printf("The kernel allows to use AMX.\n");
    }


    rc = syscall(SYS_arch_prctl, ARCH_GET_XCOMP_PERM, &bitmask);

    if (rc) {
        printf("rc error\n");
    } else  {
        if (( bitmask & XFEATURE_MASK_XTILEDATA) == 0){
            printf("verify AMX permission faild bitmask %ld\n",bitmask);
        }

    }
}
```

This request fails on the account of too small a size for sigaltstack used by CPython allocated in Modules/faulthandler.c

The stack size used is 2*SIGSTKSZ, and does not take hardware capabilities into account.

Linux kernel 5.14 adds support to query minimum size of sigaltstack dynamically via getauxval(AT_MINSIGSTKSZ).

AMX support is added in Linux kernel 5.16 

CPython should make use of this when built against more recent Linux kernels.

New changeset dc374ac7b0fabaed49461a2044c220765f48d229 by Victor Stinner in branch 'main':
bpo-46968: Add os.sysconf_names['SC_MINSIGSTKSZ'] (GH-31824)
https://github.com/python/cpython/commit/dc374ac7b0fabaed49461a2044c220765f48d229

New changeset 3b128c054885fe881c3b57a5978de3ea89c81a9c by Oleksandr Pavlyk in branch 'main':
bpo-46968: Fix faulthandler for Sapphire Rapids Xeon (GH-31789)
https://github.com/python/cpython/commit/3b128c054885fe881c3b57a5978de3ea89c81a9c

The latest faulthandler bug on sigaltstack() was bpo-21131 about FPU state stored by "XSAVE" and a Linux kernel change to fix a security vulnerability:
https://bugs.python.org/issue21131#msg349688

New changeset 393e2bf6bc6effbfe821f051a230978f0edd70df by Victor Stinner in branch '3.10':
bpo-46968: Fix faulthandler for Sapphire Rapids Xeon (GH-31789) (GH-31830)
https://github.com/python/cpython/commit/393e2bf6bc6effbfe821f051a230978f0edd70df

New changeset ba2b7956fa3932769a5c0aa2575de5c8d7e7ba4b by Victor Stinner in branch '3.9':
bpo-46968: Fix faulthandler for Sapphire Rapids Xeon (GH-31789) (GH-31831)
https://github.com/python/cpython/commit/ba2b7956fa3932769a5c0aa2575de5c8d7e7ba4b

Thanks Oleksandr Pavlyk for your nice enhancement!

I merged your change to 3.9, 3.10 and main branches! I also added os.sysconf('SC_MINSIGSTKSZ') to Python 3.11.

On my x86-64 Fedora 35 with the CPU "Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz", I get:

* SIGSTKSZ = 8192
* getauxval(AT_MINSIGSTKSZ) = 2032
* faulthandler stack.ss_size = 10224
* os.sysconf('SC_MINSIGSTKSZ') = 2032

In C, sysconf(_SC_MINSIGSTKSZ) is similar to getauxval(AT_MINSIGSTKSZ), but the glibc sysconf(_SC_MINSIGSTKSZ) is more generic, whereas IMO getauxval(AT_MINSIGSTKSZ) is more the low-level Linux API.

So where getauxval(AT_MINSIGSTKSZ) < SIGSTKSZ the merged changes actually resulted in decrease of the allocated signal deliver stack. 

On Sapphire Rapids due to tile registers size we have getauxval(AT_MINSIGSTKSZ) > SIGSTKSZ.

This is why the initial proposal was to use SIGSTKSZ + max(getauxval(AT_MINSIGSTKSZ), SIGSTKSZ).

I suppose, ultimately I am saying that we should check that bpo-21131 does not regress.

> So where getauxval(AT_MINSIGSTKSZ) < SIGSTKSZ the merged changes actually resulted in decrease of the allocated signal deliver stack. 

faulthandler stack is only used in the least likely case: on a fatal error. It should reduce its memory footprint, so it's good that it uses less memory.

To fix bpo-21131, I chose to use SIGSTKSZ * 2 because:

* the fix is trivial: add "* 2"
* it "just works"
* there was no API to query how many bytes Linux uses on the stack

Previously, faulthandler had between 0 and SIGSTKSZ bytes depending on which CPU extension was used or not on the process.

If I understood correctly, on Linux 5.14 with the change, faulthandler now always has SIGSTKSZ bytes for its own usage, and the other bytes are used by the Linux kernel. So it's more reliable for faulthandler, to always have the same amount of memory for its personal use.

Commit 393e2bf6bc6effbfe821f051a230978f0edd70df has broken CPython in RedHat 6:


[2022-03-16T18:49:20.608Z] 2022/03/16 14:48:55 ERROR /tmp/python3.10-3.10.3-0/Modules/faulthandler.c:28:12: fatal error: sys/auxv.h: No such file or directory
#  include <sys/auxv.h>
^~~~~~~~~~~~
compilation terminated.

This is problematic because this has been backported to stable releases.

We may need to revert these commits and do another release.... sigh :(

The configure file is checking for "linux/auxvec.h"

checking linux/auxvec.h usability... yes

but the code is including "sys/auxvec.h"

The code is assuming that if linux/auxvec.h then sys/auxv.h will be available, which is wrong.

This may be quite bad, because this means that 3.10 and 3.9 doesn't build in CentOS 6, which is used for manylinux2010 wheels

> Commit 393e2bf6bc6effbfe821f051a230978f0edd70df has broken CPython in RedHat 6

Too bad that we want to support RHEL 6 but have no buildbot for that.

New changeset 8e3fde728f547f1d32bde8adf62b4c50bb877b9d by Pablo Galindo Salgado in branch 'main':
bpo-46968: Check for 'sys/auxv.h' in the configure script (GH-31961)
https://github.com/python/cpython/commit/8e3fde728f547f1d32bde8adf62b4c50bb877b9d

New changeset a12ef81231d65da5efbef4fa1434716270a19af6 by Pablo Galindo Salgado in branch '3.9':
[3.9] bpo-46968: Check for 'sys/auxv.h' in the configure script (GH-31961). (GH-31975)
https://github.com/python/cpython/commit/a12ef81231d65da5efbef4fa1434716270a19af6

New changeset 6fd9737373f2bed03f409440b4fd50b9f8f121cb by Pablo Galindo Salgado in branch '3.10':
[3.10] bpo-46968: Check for 'sys/auxv.h' in the configure script (GH-31961). (GH-31974)
https://github.com/python/cpython/commit/6fd9737373f2bed03f409440b4fd50b9f8f121cb

Thanks for the fix Pablo.