From: Chiawei Wang <[email protected]>
CLOCK_REALTIME in vdso data won't be updated if
__arch_use_vsyscall() returns false. It will let time()
return an incorrect time value. Since time() is designed
to return the seconds since the Epoch, using
CLOCK_REALTIME_COARSE can still fulfill the request and
never fails.
Signed-off-by: Chiawei Wang <[email protected]>
Signed-off-by: Mark Salyzyn <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected] # 5.4+
---
lib/vdso/gettimeofday.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c
index a2909af4b924..7ea22096cbe2 100644
--- a/lib/vdso/gettimeofday.c
+++ b/lib/vdso/gettimeofday.c
@@ -324,7 +324,7 @@ __cvdso_time_data(const struct vdso_data *vd, __kernel_old_time_t *time)
vd->clock_mode == VDSO_CLOCKMODE_TIMENS)
vd = __arch_get_timens_vdso_data();
- t = READ_ONCE(vd[CS_HRES_COARSE].basetime[CLOCK_REALTIME].sec);
+ t = READ_ONCE(vd[CS_HRES_COARSE].basetime[CLOCK_REALTIME_COARSE].sec);
if (time)
*time = t;
--
2.27.0.278.ge193c7cf3a9-goog
On Jun 11, 2020, at 12:34 PM, Thomas Gleixner <[email protected]> wrote:
>
> Mark Salyzyn <[email protected]> writes:
>> From: Chiawei Wang <[email protected]>
>>
>> CLOCK_REALTIME in vdso data won't be updated if
>> __arch_use_vsyscall() returns false.
>
> Errm!
>
> # git grep __arch_use_vsyscall
> #
>
> Aside of that update_vsyscall() updates CLOCK_REALTIME data
> unconditionally. No idea what this patch is solving.
>
>> Cc: [email protected] # 5.4+
>
> This # 5.4+ is pointless. You really want to add a fixes tag which pin
> points the commit which introduced the wreckage.
>
> But thats moot as this is not fixing anything not even in 5.4.
>
> I assume this was developed against some Frankenkernel which has a messy
> backport or a snapshot of some development version of that vdso stuff.
Yes, problem code was removed with 52338415cf4d4064ae6b8dd972dadbda841da4fa not applied.
4.19 back port without time namespaces, chip vendor using __arch_use_vsyscall to solve a chip errata.
>
> Not that I want to know, but please make sure that something you send my
> way makes sense on sane kernels.
>
> Oh well.
>
> Thanks,
>
> tglx
Sorry for your troubles.
Sincerely — Mark Salyzyn
Mark Salyzyn <[email protected]> writes:
> From: Chiawei Wang <[email protected]>
>
> CLOCK_REALTIME in vdso data won't be updated if
> __arch_use_vsyscall() returns false.
Errm!
# git grep __arch_use_vsyscall
#
Aside of that update_vsyscall() updates CLOCK_REALTIME data
unconditionally. No idea what this patch is solving.
> Cc: [email protected] # 5.4+
This # 5.4+ is pointless. You really want to add a fixes tag which pin
points the commit which introduced the wreckage.
But thats moot as this is not fixing anything not even in 5.4.
I assume this was developed against some Frankenkernel which has a messy
backport or a snapshot of some development version of that vdso stuff.
Not that I want to know, but please make sure that something you send my
way makes sense on sane kernels.
Oh well.
Thanks,
tglx