[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <IAJI-AV-zUjfcYVmPMYBQWEVh9AdcmCC5YW-4XmpdGTCFkb3qlqvEfE9CeEvDObiZuzrpdhMZpo2a5PoJliXF7zpwgtXUOGsWE-eKMpNKkE=@proton.me>
Date: Sun, 18 Oct 2026 23:50:58 +0000
From: unnoticed-hassle <unnoticed-hassle@...ton.me>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: aarch64/SVE: sysconf(_SC_NPROCESSORS_ONLN) returns a wrong value because the compiler keeps sve predicate state live across the inline svc 0 syscall
OS: Gentoo Linux
Arch: armv9.2-a
Compiler: Clang 23.1.3+polly
Libc: Musl v1.2.6
Hi!
I would like to report a defect in musl on aarch64 that leads to silently
incorrect results when the library is built with the vector extensions
enabled.
On arm64 Linux the kernel zeroes the SVE state that is not shared with FPSIMD on
return from a syscall: the high bits of Z0 through Z31, all of P0 through P15,
and FFR. The aarch64 syscall wrappers in musl list only "memory" and "cc" in the
clobber list of the inline "svc 0" assembly, so the compiler may keep SVE values
live across the syscall and read them back after the kernel has already zeroed
them, producing incorrect results. This is observable with
clang >= 21 at -O2 -march=armv8-a+sve, which hoists "ptrue p0.s" above the
syscall and then uses a predicated "cnt", so the popcount forsysconf(_SC_NPROCESSORS_ONLN) sums whole mask bytes instead of counting bits.
Thanks for your time!
See also:
https://www.kernel.org/doc/html/latest/arch/arm64/sve.html#system-call-behaviour
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#simd-and-floating-point-registers
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
