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