I am pretty sure that PTHREAD_STACK_MIN was sufficient for cancellation to work on glibc 2.26 (as released) and earlier, across all architectures. The test case pretty much mirrors what ntpd does during startup, and it's so widely used that people report problems with that pretty quickly. (It's how this was reported originally.)
I think the XSAVE ld.so trampoline simply introduced a regression, and we are putting in changes to fix it (4 KiB of stack added, libgcc_s.so with RTLD_NOW). The new tests try to make sure that it won't happen again.
existing code relies on it:
https://sourceware.org/ml/libc-help/2017-02/msg00000.html
tl;dr: glibc uses dlopen for cancellation which can fail, so
the only way for ntpd to avoid crashing at runtime or leaking
blocked threads is to a cancel a thread at program startup time
(which does the dlopen early) and it uses a minimal stack to
avoid wasting resources for this nasty workaround.
So in this case I think the summary Carlos wrote about "What can
a thread do with PTHREAD_STACK_MIN?" should be changed to also
include cancellation (at least this specific scenario).