Messages in this thread | | | From | "Jason A. Donenfeld" <> | Date | Mon, 30 Dec 2019 16:39:41 +0100 | Subject | Re: [PATCH] mips: vdso: conditionalize 32-bit time functions on COMPAT_32BIT_TIME |
| |
On Mon, Dec 30, 2019 at 4:37 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Mon, Dec 30, 2019 at 3:37 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > > > On Mon, Dec 30, 2019 at 1:34 PM Arnd Bergmann <arnd@arndb.de> wrote: > > > > > > - Why does it crash in the first place rather than returning -ENOSYS? > > > > There's a bit of speculation about this in the original thread that > > prompted this patch (you're CC'd). > > > > > > > > - How does it actually work if you run an application built against > > > an old musl version on a kernel that tries to make this not work? > > > Do you just get a random time (uninitialized user space stack) and > > > work with that without checking the error code? > > > > Actually, your patch fails here. The ts struct remains as it was > > before, filled with garbage. No good. My original patch in this > > thread, though, does result in the correct value being written to ts. > > Ok, that is the intended behavior then, clock_gettime() needs > to fail with -EINVAL or -ENOSYS here (depending on the libc > implementation), and of course the data is not updated. > > Returning success from clock_gettime() on a kernel with only > time64 support and a libc with only time32 support (or vice > versa) would be a bug.
Ah, right, hence why the 32-bit compat code is behind a still-on-by-default-but-not-for-long menu option.
| |