As part of the x32 port, a number of types/struct fields which were originally "long" or "unsigned long" were changed to __syscall_slong_t or __syscall_ulong_t, when an obvious alternative choice of leaving them as "long" and adding an adjacent padding field would have been equally compatible with the kernel. In at least some cases, the use of 64-bit types poses a security risk by breaking reasonable overflow checks. For example, if len has 64-bit type but size_t is just 32-bit, then:

if (size < SIZE_MAX - len) p = malloc(size + len);

fails to detect overflows and passes a truncated size to malloc.

The first example I noticed is in sysdeps/unix/sysv/linux/x86/bits/msq.h:

typedef __syscall_ulong_t msglen_t;

I'm not sure if this one is itself dangerous.

My preference would be to have all of these usages changed from 64-bit to 32-bit with an adjacent 32-bit padding field. The risk of unexpected, possibly dangerous behavior when fields which contain lengths/counts/etc. are larger than size_t are too great, especially on a target that's still not widely used and not getting heavy testing.