It looks to me that it does have a fallback path: https://tip.golang.org/src/runtime/sys_linux_mips64x.s#L309

Does it handle your concern? Thanks.

@cherrymui That path seems to be taken only when runtime.vdsoClockgettimeSym is zero (VDSO is not available or __vdso_clock_gettime is missing). This potential issue could happen when executing __vdso_clock_gettime while using clocksource that doesn't have VDSO support [1]. I believe that in that case the code should run the existing fallback path.

[1] https://github.com/torvalds/linux/blob/v4.12/arch/mips/vdso/gettimeofday.c#L134

This does look like an issue to me, but referenced commit (torvalds/linux@180902e) does not add an appropriate fallback. That commit adds a fallback for unknown clock IDs, but Go always passes CLOCK_MONOTONIC. The ENOSYS for CLOCK_MONOTONIC when VDSO is disabled is still there.

That said, torvalds/linux@24640f2#diff-6d421860181fa4dae9db33a72099e169 (v5.4) switches to a new generic VDSO, which does have a fallback: https://github.com/torvalds/linux/blob/458ef2a25e0cbdc216012aa2b9cf549d64133b08/lib/vdso/gettimeofday.c#L293

Thanks. So, do you think we should fall back to syscall if the VDSO call returns ENOSYS, or maybe any negative result?

From a quick look over the code, it shouldn't matter, as ENOSYS is literally the only possible error. FWIW, I'd probably stick with ENOSYS, but it really doesn't matter.

For reference glibc just falls back on ENOSYS: https://github.com/bminor/glibc/blob/bc2eb9321ec0d17d41596933617b2522c9aa5e0b/sysdeps/unix/sysv/linux/sysdep-vdso.h#L41

@prattmic Is this issue resolved?

No, we still need a fallback on ENOSYS to handle kernels prior to torvalds/linux@24640f2#diff-6d421860181fa4dae9db33a72099e169 that have VDSO_CLOCK_NONE (https://github.com/torvalds/linux/blob/180902e08f051f72c89ffa366f4e4f7a8e9c753e/arch/mips/vdso/gettimeofday.c#L175-L176).

Change https://golang.org/cl/270717 mentions this issue: runtime: check mips64 VDSO clock_gettime return code

@draganmladjenovic @prattmic I can't find any available kernel before 4.13, it passed the testes on 4.19/5.4.

@mengzhuo that surprises me. Is this on a machine running that has VDSO_CLOCK_NONE.

From browsing the tree at torvalds/linux@24640f2, it seems that would be any hardware not using the "R4K" clock source:

$ grep -R clock_mode arch/mips
...
arch/mips/kernel/csrc-r4k.c:            clocksource_mips.archdata.vdso_clock_mode = VDSO_CLOCK_R4K;

Other clock sources, like "OCTEON_CVMCOUNT" (arch/mips/cavium-octeon/csrc-octeon.c) don't seem to provide a VDSO clock mode and would thus return ENOSYS.

I'm not at all familiar with MIPS hardware. Do these configurations not exist in practice?

I'm not at all familiar with MIPS hardware. Do these configurations not exist in practice?

If I remember correctly, all linux-mips*-rtrk builders happen to use OCTEON_CVMCOUNT, but the kernel was built w/o VDSO support at all because of that.

@prattmic
AFAIK It's not necessary setting clock_mode any kernel with CONFIG_HIGH_RES_TIMERS=y will got a "Constant" clocksource on mips
I did the tests on my Loongson box (linux-mips64le-mengzhuo, Linux 5.4)

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
Constant hpet

Linux 5.4 will safely fallback to syscall and ret 0 if I switch to hpet, which has no vdso support.

@mengzhuo that surprises me. Is this on a machine running that has VDSO_CLOCK_NONE.

From browsing the tree at torvalds/linux@24640f2, it seems that would be any hardware not using the "R4K" clock source:

$ grep -R clock_mode arch/mips
...
arch/mips/kernel/csrc-r4k.c:            clocksource_mips.archdata.vdso_clock_mode = VDSO_CLOCK_R4K;

Other clock sources, like "OCTEON_CVMCOUNT" (arch/mips/cavium-octeon/csrc-octeon.c) don't seem to provide a VDSO clock mode and would thus return ENOSYS.

I'm not at all familiar with MIPS hardware. Do these configurations not exist in practice?

@prattmic
@draganmladjenovic

Any updates? I think we can merge the fix in Go1.16

@mengzhuo Sorry, I didn't have a chance to test this on the offending versions of the kernel. Your change looks fine to me. I guess that it should also be backported to 1.14 and 1.15.