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 dc374ac by Victor Stinner in branch 'main':
bpo-46968: Add os.sysconf_names['SC_MINSIGSTKSZ'] (GH-31824)
dc374ac

New changeset 3b128c0 by Oleksandr Pavlyk in branch 'main':
bpo-46968: Fix faulthandler for Sapphire Rapids Xeon (GH-31789)
3b128c0

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 393e2bf by Victor Stinner in branch '3.10':
bpo-46968: Fix faulthandler for Sapphire Rapids Xeon (GH-31789) (GH-31830)
393e2bf

New changeset ba2b795 by Victor Stinner in branch '3.9':
bpo-46968: Fix faulthandler for Sapphire Rapids Xeon (GH-31789) (GH-31831)
ba2b795

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 393e2bf 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 393e2bf has broken CPython in RedHat 6

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

New changeset 8e3fde7 by Pablo Galindo Salgado in branch 'main':
bpo-46968: Check for 'sys/auxv.h' in the configure script (GH-31961)
8e3fde7

New changeset a12ef81 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)
a12ef81

New changeset 6fd9737 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)
6fd9737

Thanks for the fix Pablo.