[PATCH 5/7] MIPS: VDSO: Drop kconfig MIPS_CLOCK_VSYSCALL
Arnd Bergmann
arnd at arndb.de
Fri Feb 27 02:03:30 PST 2026
On Fri, Feb 27, 2026, at 10:31, Thomas Weißschuh wrote:
> On Fri, Feb 27, 2026 at 09:46:23AM +0100, Arnd Bergmann wrote:
>> On Fri, Feb 27, 2026, at 07:57, Thomas Weißschuh wrote:
>>
>> The #ifdef was originally been added in commit 7d2aa4bb90f5 ("mips:
>> Fix gettimeofday() in the vdso library") as a bug fix. This may not
>> have been the correct fix because I don't see how it addressed the
>> case of a kernel with MIPS_CLOCK_VSYSCALL enabled running on a
>> CPU without the timer registers, but I think we should try to make
>> sure that there is no regression from reverting it now.
>
> I can't make sense out of this commit. The generic vDSO automatically falls
> back to the syscall if it can not handle the current clocksource.
> There is no explanation *why* this should be broken on MIPS.
> It works correctly on my x86 machines.
Agreed, the explanation is incomplete at best. Maybe Vincenzo remembers
more details as he did the original patch.
Maybe the fallback logic didn't exist at the time of that fix?
> Also vdso_clock_gettime() uses the same codepaths as vdso_gettimeofday()
> and apparently that is not broken.
Not sure, maybe nobody noticed the bug yet, or maybe both
vdso_gettimeofday() and vdso_clock_gettime() now work correctly
after another bugfix.
The condition is fairly rare, as almost all MIPS systems have
a working clocksource, the few exceptions I see in Kconfig are
- R3000 based DECstation
- Sibyte
- Ingenic Xburst
- Octeon
There are not many users left on R3000 and Sibyte platforms, but
Xburst and Octeon were reasonably common in the past, so it should
have come up at some point.
>> config MIPS_DISABLE_VDSO
>> - def_bool CPU_MICROMIPS
>> + def_bool CPU_MICROMIPS || !(CSRC_R4K || CLKSRC_MIPS_GIC)
>
> That is an an independent optimization IMO.
The idea here was that doing this would save you the trouble
of figuring out exactly how it was broken in the past and
whether the #ifdef is still needed.
Arnd
More information about the linux-arm-kernel
mailing list