time_t assessment of what needs to be done

time_t assessment of what needs to be done

[Rich Felker]

Regardless of how we handle ABI, there's some fixed amount of work
that has to be done for actually implementing 64-bit time_t support on
archs where it was not historically 64-bit, without breaking the
ability to run on older kernels. At least the following interfaces
need to check (via #ifdef on the syscall numbers or or some
syscall_arch.h provided macro) whether there's a time64 version of
their operation, and if so, not only use it, but also check for ENOSYS
or equivalent and fallback to performing conversions and using the old
syscalls:

- clock_gettime
- clock_settime
- clock_adjtime
- timer_gettime
- timer_settime
- timerfd_gettime
- timerfd_settime
- utimensat
- mq_timedsend
- mq_timedreceive
- semtimedop
- clock_nanosleep
- stat
- fstat
- lstat
- fstatat

Then there are some functions that can get by without using the new
syscall at all (avoiding the need for fallback logic), but that need
to convert relative times or such between legacy kernel format and new
userspace format:

- nanosleep
- clock_getres
- sched_rr_get_interval
- pselect
- ppoll
- sigtimedwait
- recvmmsg
- __timedwait
- getrusage

The adjtime function is probably also in this category, but it should
probably just be rewritten not to use the syscall directly, but in
terms of clock_adjtime. Same for adjtimex.

Next, for these functions:

- setsockopt
- getsockopt
- ioctl

there are also affected commands, at least:

- SO_TIMESTAMP
- SO_TIMESTAMPNS
- SO_TIMESTAMPING
- SO_RCVTIMEO
- SO_SNDTIMEO

For these we need to change the macro numbers to the new 64-bit ones,
and provide fallback code so that, if the kernel doesn't recognize the
new command, it's retried with the old one and conversion.

Finally, the sysvipc stuff is the worst. These functions require
decoding endian-swapped time_t values or bits stuffed into
reserved/padding areas of the legacy structs into whatever new
application-facing structs we use:

- shmctl
- semctl
- msgctl

It's not clear to me if glibc has decided (or even started on) new
layouts of the affected structs (shmid_ds, semid_ds, msqid_ds). Since
keeping ABI-compat is desirable, we should figure this out asap.

A few misc issues I also found:

The utmp structure has just enough reserved space to move ut_tv to the
end and make it unconditionally 64-bit-time_t. This is also nice for
mixed 32/64-bit systems. Of course musl's utmp stuff is nopped out
anyway but the types should be fixed for users of third-party utmp
tooling/libraries. Alternatively we could just change it, since it's
not an app-libc ABI at this point as far as I can tell. Matching the
current 64-bit layout might be more useful than changing both.

And.. sys/procfs.h has soem timevals in struct elf_prstatus. I'm not
sure if this is on-disk ABI, if so with what, and whether it's even
used anymore anyway. This probably needs to be investigated. I'd love
to rip it out if it's not needed.

And.. sys/timex.h has struct ntptimeval with a legacy timeval inside.
There don't seem to be any libc interfaces that use it, but maybe
something else does...


Now, back ot ABI. In addition to the above mentioned functions, the
following also have time_t or derived types in their interfaces, but
don't depend on syscalls, only on other underlying functions that
would already accept the userspace time_t/timeval/timespec form:

- pthread_mutex_timedlock
- pthread_cond_timedwait
- pthread_rwlock_timedrdlock
- pthread_rwlock_timedwdlock
- sem_timedwait
- mtx_timedlock
- cnd_timedwait
- thrd_sleep
- sleep
- time
- gettimeofday
- settimeofday
- difftime
- mktime
- gmtime
- localtime
- ctime
- gmtime_t
- localtime_r
- ctime_r
- stime
- timegm
- utime
- ftime
- utimes
- futimes
- futimesat
- lutimes
- futimens

I may have missed some; that list was built by grepping headers
casually.

If doing the ".2 ABI", no action would be needed on these; they just
automatically switch over. If we do the transition that avoids forcing
a hard ABI switchover, these as well as all the earlier-mentioned
functions will need header-level redirects, and legacy wrappers to
satisfy references to the legacy functions. By my sloppy count, that's
about 60 redirects/new-symbols, not horrible, but probably a little
bit more than I expected.

Rich

Re: time_t assessment of what needs to be done

[A. Wilcox]

[-- Attachment #1.1: Type: text/plain, Size: 1166 bytes --]

On 07/01/19 15:11, Rich Felker wrote:
> The utmp structure has just enough reserved space to move ut_tv to the
> end and make it unconditionally 64-bit-time_t. This is also nice for
> mixed 32/64-bit systems. Of course musl's utmp stuff is nopped out
> anyway but the types should be fixed for users of third-party utmp
> tooling/libraries. Alternatively we could just change it, since it's
> not an app-libc ABI at this point as far as I can tell. Matching the
> current 64-bit layout might be more useful than changing both.

With my official distro hat on, I can say that we have no preference:

[quoting system/musl/APKBUILD]

        # replaced by utmps - don't allow apps to sneak use of no-ops
        rm "$pkgdir"/usr/include/utmp.h
        rm "$pkgdir"/usr/include/utmpx.h


With my official distro hat off, I don't know if musl is trying to be
compatible with glibc ABI here as well.  If so, you should see what
they're doing to the layout of the utmp structure, because most apps
will write the structure directly to the disk.


Best,
--arw

-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: time_t assessment of what needs to be done

[Rich Felker]

On Mon, Jul 01, 2019 at 04:11:07PM -0400, Rich Felker wrote:
> Then there are some functions that can get by without using the new
> syscall at all (avoiding the need for fallback logic), but that need
> to convert relative times or such between legacy kernel format and new
> userspace format:
> 
> - nanosleep
> - clock_getres
> - sched_rr_get_interval
> - pselect
> - ppoll
> - sigtimedwait
> - recvmmsg
> - __timedwait
> - getrusage

Arnd noted additions to this list:

- setitimer
- getitimer
- wait3
- wait4

And additional functions that have indirect time_t dependency in their
interfaces that may need redirection if redirection is done:

- aio_suspend
- sched_getparam
- sched_setparam
- sched_setscheduler
- pthread_getschedparam
- pthread_setschedparam
- pthread_attr_getschedparam
- pthread_attr_setschedparam
- posix_spawnattr_getschedparam
- posix_spawnattr_setschedparam

My leaning for the schedparam stuff is actually not to do any
redirctions, but instead remove the SCHED_SPORADIC cruft (Linux has
never supported it and almost surely won't) and instead replace the
members with "unused" fields of the same size that we could later
repurpose for something else useful.

Rich