Re: [PATCH 1/2] vdso: sparc: stub out custom vdso implementation

["Arnd Bergmann" <arnd@arndb.de>]

On Tue, Jul 8, 2025, at 07:39, Thomas Weißschuh wrote:
> On Mon, Jul 07, 2025 at 04:46:37PM +0200, Arnd Bergmann wrote:
>> 
>>   sparc-linux-ld: warning: arch/sparc/vdso/vdso-note.o: missing .note.GNU-stack section implies executable stack
>>   sparc-linux-ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
>
> IMO this should be in its own patch.

Fair enough, I considered splitting up my patch further already but
tried to keep it simple. This one does make sense to split out though.

>> Most of the removed code only exists on sparc in order to dynamically
>> patch the vdso based on the presence of the tick vs vtick based
>> clocksource.
>> 
>> Rip out the whole thing and replace it with a minimal stub as we do
>> on parisc and uml. This introduces a small performance regression when
>> using a libc that is aware of the vdso (glibc-2.29 or higher).
>> 
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Thanks, this makes things easier.
>
> Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> Tested-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
>
> But why do we even need the stubs? Removing the time functions from the
> vDSO completely should also work, no?
> For parisc there was no reasoning why stubs were used. On uml the stubs are
> necessary to prevent the libc from calling into the host vsyscall [0], but
> that looks irrelevant for SPARC.
>
> [0] f1c2bb8b9964 ("um: implement a x86_64 vDSO")

I was wondering about this myself, I thought this might have been
for runtime environments that just assume the vDSO is there, possibly
some non-C libraries, or future glibc versions that may error
out when the vdso is absent instead of falling back to the syscall.

The 5f55e098b8d0 ("parisc: Add 64-bit gettimeofday() and
clock_gettime() vDSO functions") commit and the corresponding
glibc patch one don't have any explanation unfortunately, but
maybe Helge can explain why this is needed.

The arch/x86/um/vdso/um_vdso.c version for 32-bit seems to still
be missing the clock_gettime64() entry, any idea what the
resulting behavior is for time64 userspace?

      Arnd