On Wed, Dec 18, 2024 at 05:35:31PM +0100, Arnd Bergmann wrote:

On Wed, Dec 18, 2024, at 16:46, Thomas Weißschuh wrote:

quoted

On Wed, Dec 18, 2024 at 03:08:28PM +0000, Conor Dooley wrote:

quoted

On Mon, Dec 16, 2024 at 03:10:03PM +0100, Thomas Weißschuh wrote:

quoted

quoted

Might be a clang thing, allmodconfig with clang doesn't build either.

The proposed generic storage infrastructure currently expects that all
its users also use HAVE_GENERIC_VDSO.
I missed rv32 when checking this assumption.

I can add a bunch of ifdefs into the storage code to handle this.

Or we re-add the time vDSO functions which were removed in commit
d4c08b9776b3 ("riscv: Use latest system call ABI").
Today there are upstream ports of musl and glibc which can use them.
(currently musl even tries to use __vdso_clock_gettime() as 64-bit only
on rv32 due to a copy-and-paste error from its rv64 code)

Adding back __vdso_clock_gettime() wouldn't work on rv32 because there
is no fallback syscall for it, and it wouldn't really help since
there is no existing userspace that uses time32 structures.

My original paragraph was worded confusingly.
It was about re-adding time-related vDSO function *in general*, not the
specific 32-bit ones.
The new ones should be 64-bit only, indeed.

quoted

There is precedence in providing 64bit only vDSO functions, for example
__vdso_clock_gettime64() in arm.
I do have a small, so far untested, proof-of-concept patch for it.
This would even be less code than the ifdefs.

What do you think about it?

Yes, simply exposing the normal time64 syscalls through vdso
should be fine. I think this currently works on everything except
rv32 and sparc32, probably because neither of them have actual
users that are able to test.

Should it use the specific _vdso_clock_gettime64() naming or leave out
the 64 suffix?


General Note: I'll continue working on this next year.


Thanks,
Thomas