Re: 32-bit time_t inside itimerval

[Arnd Bergmann <arnd@arndb.de>]

On Fri, Dec 20, 2019 at 10:35 PM Alistair Francis <alistair23@gmail.com> wrote:
>
> Hey,
>
> I just noticed something strange.
>
> The setitimer syscall is not different for 32/64-bit time_t. So we use
> this syscall for both 32/64 time_t [1]
>
> SYSCALL_DEFINE3(setitimer, int, which, struct itimerval __user *, value,
>         struct itimerval __user *, ovalue)
>
> Where struct itimerval __user *, value looks like this [2]:
>
> struct itimerval {
>     struct timeval it_interval;    /* timer interval */
>     struct timeval it_value;    /* current value */
> };
>
> Which then uses this structure for timeval [3]:
>
> struct timeval {
>     __kernel_old_time_t    tv_sec;        /* seconds */
>     __kernel_suseconds_t    tv_usec;    /* microseconds */
> };
>
> And __kernel_old_time_t is defined [4] as:
>
> typedef __kernel_long_t    __kernel_old_time_t;
> typedef __kernel_long_t    __kernel_time_t;

Right, with my latest patches, this gets changed to __kernel_old_timeval, with
an unmodified definititon.

> So __kernel_old_time_t and __kernel_time_t are both 32-bit values
> inside the kernel. and the setiimer syscall expects a 32-bit time_t
> for the values inside it.
>
> This is different to the current glibc implementation where all time_t
> values are treated as 64-bit for RISC-V [5].
>
> What should we do here?
>
> 1. Change glibc to use a 32-bit time_t for some structures, such as
> the timeval inside itimerval?
> 2. Convert the kernel time_t to be 64-bit for RV32?

What happened here is that originally I thought we would not need
setitimer/getitimer
and could fall back to timer_settime/timer_gettime, but that turned out to be a
misunderstanding (we do need both).

By the time we introduced all the other system calls with 64-bit
time_t in linux-5.1,
there was no replacement yet, but since these interfaces never pass
absolute times
on the kernel ABI, it was considered good enough. There was a small debate on
whether struct itimerval and struct rusage (which has the same problem) should
have replacements using struct __kernel_timespec, or a newly added
__kernel_timeval, and that discussion never had a conclusion, so we
left it at this.

For glibc, the only sensible implementation is to implement the time64
settimer/getitimer interfaces on top of the time32 setitimer/getitimer
system calls,
doing the conversion internally. (Same for getrusage and wait4).

We may still want to introduce getitimer_time64, setiitimer_timer64,
getrusage_time64 and waitid_time64 at some point, using __kernel_timespec
to have a saner user space interface, but there is no real point in glibc
using those syscalls as the underlying implementation when the fallback
to the time32 versions is still required.

        Arnd