Re: [PATCH v6] y2038: Introduce __ASSUME_TIME64_SYSCALLS define

[Stepan Golosunov <stepan at golosunov dot pp dot ru>]

Resending as this was truncated yesterday.

31.05.2019 в 14:49:02 +0400 Stepan Golosunov написал:
> 30.05.2019 в 16:01:12 +0000 Joseph Myers написал:
> > On Wed, 29 May 2019, Lukasz Majewski wrote:
> > 
> > >   List of new syscalls added to v5.1. kernel (they accept data based on
> > >   struct timespec and timeval with 64 bit tv_sec):
> > > 
> > >    clock_gettime64
> > >    clock_settime64
> > >    clock_adjtime64
> > >    clock_getres_time64
> > >    clock_nanosleep_time64
> > >    timer_gettime64
> > >    timer_settime64
> > >    timerfd_gettime64
> > >    timerfd_settime64
> > >    utimensat_time64
> > >    pselect6_time64
> > >    ppoll_time64
> > >    io_pgetevents_time64
> > >    recvmmsg_time64
> > >    mq_timedsend_time64
> > >    mq_timedreceive_time64
> > >    semtimedop_time64
> > >    rt_sigtimedwait_time64
> > >    futex_time64
> > >    sched_rr_get_interval_time64
> > 
> > I do *not* think semtimedop_time64 should be included in the set of 
> > syscalls.  I think that if the macro is defined on systems with __WORDSIZE 
> > == 64, it should *only* relate to syscalls where the syscall semantics are 
> > *identical* for both the old syscall (on systems where __WORDSIZE or 
> > __SYSCALL_WORDSIZE is 64) and for the new one, so that no code will ever 
> > have to handle the two syscalls differently.  And the comment should 
> > explicitly say that it is only for that subset of syscalls.
> 
> There is already a macro to specify whether semtimedop semantics is
> available: __ASSUME_DIRECT_SYSVIPC_SYSCALLS.  It should be always
> defined for 5.1+ kernels.  (Lack of support for __NR_semtimedop_time64
> in glibc is one of the obstacles in the way of defining
> __ASSUME_DIRECT_SYSVIPC_SYSCALLS currently.)
> 
> I see how splitting semtimedop/semtimedop_time64
> availability from __ASSUME_DIRECT_SYSVIPC_SYSCALLS can help to
> untangle __ASSUME_DIRECT_SYSVIPC_SYSCALLS from time64.  (It would
> probably be overkill though—in the end splitted macro would be defined
> exactly at the same time as __ASSUME_DIRECT_SYSVIPC_SYSCALLS.)
> 
> I fail to see how not using __ASSUME_TIME64_SYSCALLS can add anything
> but extra complexity into the following logic:
> 
> defined __ASSUME_TIME64_SYSCALLS
>   && defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS
>   && defined __NR_semtimedop_time64:
>     call semtimedop_time64
> 
> defined __ASSUME_TIME64_SYSCALLS
>   && defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS
>   && !defined __NR_semtimedop_time64:
>     call semtimedop
> 
> defined __ASSUME_TIME64_SYSCALLS
>   && !defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS:
>     (must not happen when __LINUX_KERNEL_VERSION >= 0x050100)
>     call ipc with IPCOP_semtimedop
> 
> !defined __ASSUME_TIME64_SYSCALLS
>   && defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS:
>     try __NR_semtimedop_time64, fallback to 32-bit semtimedop
> 
> !defined __ASSUME_TIME64_SYSCALLS
>   && !defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS:
>     try __NR_semtimedop_time64, fallback to 32-bit ipc with IPCOP_semtimedop
>