On Sat, Nov 8, 2025, at 01:17, Andy Lutomirski wrote:
> On Thu, Nov 6, 2025, at 2:01 AM, Thomas Weißschuh wrote:
>
> Now I'm not an expert on any architecture that has these aliasing
> (coloring?) issues, but from my limited understanding, it ought to be
> possible to choose a correctly colored address to map the vdso data
> given where it's being mapped from. If there's an issue with gathering
> a bunch of basically arbitrarily relatively positioned physical pages
> into their necessary arrangement in usermode, you could presumably fix
> it either with some linker script magic or by rearranging the C code to
> stick everything into a multipage structure.
On 32-bit Arm, we only allow VDSO on CPUs that have nonaliasing caches
but not on the rare ARMv4/v5 CPUs. From the public information I could
find, it appears that similarly all SPARC CPUs from the past 20 years
(Leon 3/4/5, SPARC64, Niagara, M5/M6/M7/M8, ...) are also nonaliasing,
though at least UltraSPARC IV (released 2004) and earlier models still
had an aliasing VIPT dcache.
Someone more familiar with SPARC should double-check that, but I would
expect that we can gate the VDSO on the actual cache topology.
On other architectures, I see that parisc (always aliasing) has stubbed
out the vdso functions, while mips/loongson has limited the page size
selection to never alias. A few other mips platforms can theoretically
enable both small pages and vdso, but my guess is that in practice
they don't use the vdso (mips32/ath79) or they use 16KB pages
(rm, dec, ip22) based on the defconfig settings.
Arnd
