[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871s398vas.fsf@concordia.ellerman.id.au>
Date: Fri, 15 Mar 2019 00:00:59 +1100
From: Michael Ellerman <mpe@...erman.id.au>
To: Arnd Bergmann <arnd@...db.de>
Cc: linuxppc-dev@...abs.org, Thomas Gleixner <tglx@...utronix.de>,
Stephen Boyd <sboyd@...nel.org>,
John Stultz <john.stultz@...aro.org>, jaydee@...il.cz,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Vincenzo Frascino <vincenzo.frascino@....com>
Subject: Re: [PATCH] powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038
Arnd Bergmann <arnd@...db.de> writes:
> On Wed, Mar 13, 2019 at 2:14 PM Michael Ellerman <mpe@...erman.id.au> wrote:
>
>> That causes CLOCK_MONOTONIC to jump ahead by ~4 billion seconds which
>> it is not meant to do. Worse, if the time is then set back before the
>> Y2038 boundary CLOCK_MONOTONIC will jump backward.
>>
>> We can fix it simply by storing the full 64-bit offset in the
>> vdso_data, and using that in the VDSO assembly code. We also shuffle
>> some of the fields in vdso_data to avoid creating a hole.
>
> I see nothing wrong with your patch,
Thanks.
> but I would point out that there is a patch series [1] from Vincenzo
> Frascino to unify the vdso implementation across architectures that I
> hope can make it into linux-5.2, and that will resolve this issue, as
> well as allow 32-bit architectures to provide a working interface with
> 64-bit time_t.
Yeah I did see that series. I will try and keep an eye on it, though I'm
not sure I'll have time to convert powerpc to use it for 5.2.
I'm also not sure how easy it's going to be to convert to the C
versions, because our syscall ABI is not a simple function call (result
code is returned in CR0.SO).
cheers
Powered by blists - more mailing lists