Update kernel-features.h files for Linux 5.1

  Linux 5.1 adds missing syscalls to the syscall table for many Linux
kernel architectures.  This patch updates the kernel-features.h
headers accordingly.  I believe the statfs64 structure used by alpha
matches what the new kernel syscalls use, but that should be reviewed
carefully.

Tested with build-many-glibcs.py.

2019-05-09  Joseph Myers  <joseph@codesourcery.com>

	* sysdeps/unix/sysv/linux/alpha/kernel-features.h
	(__ASSUME_STATFS64): Only undefine if [__LINUX_KERNEL_VERSION <
	0x050100].
	* sysdeps/unix/sysv/linux/i386/kernel-features.h
	(__ASSUME_DIRECT_SYSVIPC_SYSCALLS): Likewise.
	* sysdeps/unix/sysv/linux/ia64/kernel-features.h (__ASSUME_STATX):
	Likewise.
	* sysdeps/unix/sysv/linux/m68k/kernel-features.h
	(__ASSUME_DIRECT_SYSVIPC_SYSCALLS): Likewise.
	* sysdeps/unix/sysv/linux/mips/kernel-features.h
	(__ASSUME_DIRECT_SYSVIPC_SYSCALLS): Likewise.
	* sysdeps/unix/sysv/linux/powerpc/kernel-features.h
	(__ASSUME_DIRECT_SYSVIPC_SYSCALLS): Likewise.
	* sysdeps/unix/sysv/linux/s390/kernel-features.h
	(__ASSUME_DIRECT_SYSVIPC_SYSCALLS): Likewise.
	* sysdeps/unix/sysv/linux/sh/kernel-features.h
	(__ASSUME_DIRECT_SYSVIPC_SYSCALLS): Likewise.
	(__ASSUME_STATX): Likewise.
	* sysdeps/unix/sysv/linux/sparc/kernel-features.h
	(__ASSUME_DIRECT_SYSVIPC_SYSCALLS): Likewise.
  

09.05.2019 в 23:00:37 +0000 Joseph Myers написал:
> Linux 5.1 adds missing syscalls to the syscall table for many Linux
> kernel architectures.  This patch updates the kernel-features.h
> headers accordingly.  I believe the statfs64 structure used by alpha
> matches what the new kernel syscalls use, but that should be reviewed
> carefully.
> 
> Tested with build-many-glibcs.py.

The newly added direct ipc syscalls are different from the old ones:

1. They do not accept IPC_64.  This means that __IPC_64 should be set
to zero when new syscalls are used.  And new syscalls can not be used
for compat functions like __old_semctl.

(Hmm.  Is __old_msgctl already buggy due to its use of __IPC_64 when
__ASSUME_DIRECT_SYSVIPC_SYSCALLS is defined?  Is there any
architecture with both __ASSUME_DIRECT_SYSVIPC_SYSCALLS and
__old_msgctl currently?)

2. semtimedop does not exist on 32-bit ABIs.  They have
semtimedop_time64 instead.
(I also think that ipc with IPCOP_semtimedop was accidentally made to
behave like semtimedop_time64 in 32-bit builds of linux 5.1.  But that
would be a kernel bug.)

> diff --git a/sysdeps/unix/sysv/linux/i386/kernel-features.h b/sysdeps/unix/sysv/linux/i386/kernel-features.h
> index 3ac725b5a2..8610651346 100644
> --- a/sysdeps/unix/sysv/linux/i386/kernel-features.h
> +++ b/sysdeps/unix/sysv/linux/i386/kernel-features.h
> @@ -43,8 +43,10 @@
>  # undef __ASSUME_SENDTO_SYSCALL
>  #endif
>  
> -/* i686 only supports ipc syscall.  */
> -#undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> +/* i686 only supports ipc syscall before 5.1.  */
> +#if __LINUX_KERNEL_VERSION < 0x050100
> +# undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> +#endif
>  
>  #undef __ASSUME_CLONE_DEFAULT
>  #define __ASSUME_CLONE_BACKWARDS	1

> diff --git a/sysdeps/unix/sysv/linux/m68k/kernel-features.h b/sysdeps/unix/sysv/linux/m68k/kernel-features.h
> index 1976724362..1467474b8a 100644
> --- a/sysdeps/unix/sysv/linux/m68k/kernel-features.h
> +++ b/sysdeps/unix/sysv/linux/m68k/kernel-features.h
> @@ -50,5 +50,7 @@
>  # undef __ASSUME_SET_ROBUST_LIST
>  #endif
>  
> -/* m68k only supports ipc syscall.  */
> -#undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> +/* m68k only supports ipc syscall before 5.1.  */
> +#if __LINUX_KERNEL_VERSION < 0x050100
> +# undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> +#endif
> diff --git a/sysdeps/unix/sysv/linux/mips/kernel-features.h b/sysdeps/unix/sysv/linux/mips/kernel-features.h
> index c341c3fa10..8114090913 100644
> --- a/sysdeps/unix/sysv/linux/mips/kernel-features.h
> +++ b/sysdeps/unix/sysv/linux/mips/kernel-features.h
> @@ -31,8 +31,10 @@
>     pairs to start with an even-number register.  */
>  #if _MIPS_SIM == _ABIO32
>  # define __ASSUME_ALIGNED_REGISTER_PAIRS	1
> -/* mips32 only supports ipc syscall.  */
> -# undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> +/* mips32 only supports ipc syscall before 5.1.  */
> +# if __LINUX_KERNEL_VERSION < 0x050100
> +#  undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> +# endif
>  
>  /* The o32 MIPS fadvise64 syscall behaves as fadvise64_64.  */
>  # define __ASSUME_FADVISE64_AS_64_64		1
> diff --git a/sysdeps/unix/sysv/linux/powerpc/kernel-features.h b/sysdeps/unix/sysv/linux/powerpc/kernel-features.h
> index 413a185db3..5924534c22 100644
> --- a/sysdeps/unix/sysv/linux/powerpc/kernel-features.h
> +++ b/sysdeps/unix/sysv/linux/powerpc/kernel-features.h
> @@ -44,8 +44,10 @@
>  
>  #include_next <kernel-features.h>
>  
> -/* powerpc only supports ipc syscall.  */
> -#undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> +/* powerpc only supports ipc syscall before 5.1.  */
> +#if __LINUX_KERNEL_VERSION < 0x050100
> +# undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> +#endif
>  
>  #undef __ASSUME_CLONE_DEFAULT
>  #define __ASSUME_CLONE_BACKWARDS	1
> diff --git a/sysdeps/unix/sysv/linux/s390/kernel-features.h b/sysdeps/unix/sysv/linux/s390/kernel-features.h
> index 8fdf38c454..dcbf1c7c53 100644
> --- a/sysdeps/unix/sysv/linux/s390/kernel-features.h
> +++ b/sysdeps/unix/sysv/linux/s390/kernel-features.h
> @@ -45,8 +45,10 @@
>  # undef __ASSUME_SENDTO_SYSCALL
>  #endif
>  
> -/* s390 only supports ipc syscall.  */
> -#undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> +/* s390 only supports ipc syscall before 5.1.  */
> +#if __LINUX_KERNEL_VERSION < 0x050100
> +# undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> +#endif
>  
>  #undef __ASSUME_CLONE_DEFAULT
>  #define __ASSUME_CLONE_BACKWARDS2
> diff --git a/sysdeps/unix/sysv/linux/sh/kernel-features.h b/sysdeps/unix/sysv/linux/sh/kernel-features.h
> index 767df721b8..8532cccadd 100644
> --- a/sysdeps/unix/sysv/linux/sh/kernel-features.h
> +++ b/sysdeps/unix/sysv/linux/sh/kernel-features.h
> @@ -41,8 +41,10 @@
>     before the offset.  */
>  #define __ASSUME_PRW_DUMMY_ARG	1
>  
> -/* sh only supports ipc syscall.  */
> -#undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> +/* sh only supports ipc syscall before 5.1.  */
> +#if __LINUX_KERNEL_VERSION < 0x050100
> +# undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> +#endif
>  
>  /* Support for several syscalls was added in 4.8.  */
>  #if __LINUX_KERNEL_VERSION < 0x040800

> diff --git a/sysdeps/unix/sysv/linux/sparc/kernel-features.h b/sysdeps/unix/sysv/linux/sparc/kernel-features.h
> index f441bd811d..7b5db4af17 100644
> --- a/sysdeps/unix/sysv/linux/sparc/kernel-features.h
> +++ b/sysdeps/unix/sysv/linux/sparc/kernel-features.h
> @@ -58,8 +58,10 @@
>  # undef __NR_pause
>  #endif
>  
> -/* sparc only supports ipc syscall.  */
> -#undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> +/* sparc only supports ipc syscall before 5.1.  */
> +#if __LINUX_KERNEL_VERSION < 0x050100
> +# undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
> +#endif
>  
>  /* Support for the renameat2 syscall was added in 3.16.  */
>  #if __LINUX_KERNEL_VERSION < 0x031000
  

10.05.2019 в 14:27:13 +0400 Stepan Golosunov написал(а):
> 09.05.2019 в 23:00:37 +0000 Joseph Myers написал:
> > Linux 5.1 adds missing syscalls to the syscall table for many Linux
> > kernel architectures.  This patch updates the kernel-features.h
> > headers accordingly.  I believe the statfs64 structure used by alpha
> > matches what the new kernel syscalls use, but that should be reviewed
> > carefully.
> > 
> > Tested with build-many-glibcs.py.
> 
> The newly added direct ipc syscalls are different from the old ones:
> 
> 1. They do not accept IPC_64.  This means that __IPC_64 should be set
> to zero when new syscalls are used.  And new syscalls can not be used
> for compat functions like __old_semctl.
> 
> (Hmm.  Is __old_msgctl already buggy due to its use of __IPC_64 when
> __ASSUME_DIRECT_SYSVIPC_SYSCALLS is defined?  Is there any
> architecture with both __ASSUME_DIRECT_SYSVIPC_SYSCALLS and
> __old_msgctl currently?)
> 
> 2. semtimedop does not exist on 32-bit ABIs.  They have
> semtimedop_time64 instead.
> (I also think that ipc with IPCOP_semtimedop was accidentally made to
> behave like semtimedop_time64 in 32-bit builds of linux 5.1.  But that
> would be a kernel bug.)

And, after rereading
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0d6040d4681735dfc47565de288525de405a5c99

3. There is no semop. semtimedop(_time64)? should be used instead.
  

On 10/05/2019 07:27, Stepan Golosunov wrote:
> 09.05.2019 в 23:00:37 +0000 Joseph Myers написал:
>> Linux 5.1 adds missing syscalls to the syscall table for many Linux
>> kernel architectures.  This patch updates the kernel-features.h
>> headers accordingly.  I believe the statfs64 structure used by alpha
>> matches what the new kernel syscalls use, but that should be reviewed
>> carefully.
>>
>> Tested with build-many-glibcs.py.
> 
> The newly added direct ipc syscalls are different from the old ones:
> 
> 1. They do not accept IPC_64.  This means that __IPC_64 should be set
> to zero when new syscalls are used.  And new syscalls can not be used
> for compat functions like __old_semctl.

So it seems we will need to conditionally set __IPC_64 based on kernel
version. It also seems that our default value on generic ipc_priv.h
is not really expressing the kernel ABI.

> 
> (Hmm.  Is __old_msgctl already buggy due to its use of __IPC_64 when
> __ASSUME_DIRECT_SYSVIPC_SYSCALLS is defined?  Is there any
> architecture with both __ASSUME_DIRECT_SYSVIPC_SYSCALLS and
> __old_msgctl currently?)

The architectures that exports msgctl@GLIBC_2.0 as compat symbol are
alpha, i686, m68k, mips-o32, powerpc32, s390-32, and sparc32. And
from these one alpha currently is the only architecture that defines
__ASSUME_DIRECT_SYSVIPC_SYSCALLS. So it is buggy for alpha currently
and it would be for the aforementioned architectures once they
start to use wire-up syscall.


> 
> 2. semtimedop does not exist on 32-bit ABIs.  They have
> semtimedop_time64 instead.
> (I also think that ipc with IPCOP_semtimedop was accidentally made to
> behave like semtimedop_time64 in 32-bit builds of linux 5.1.  But that
> would be a kernel bug.)

So it seems we would need to either add an __ASSUME specific for semtimedop
to just enable wire-up calls if time64 is defined or add another pre-processor
check to see if __NR_semtimeop is defined as well.


To summarize, I think we need too:

1. Fix Linux msgctl compat function to remove __IPC64.

2. Move __IPC64 to kernel-feature.h and define it based on kernel version
   along with __ASSUME_DIRECT_SYSVIPC_SYSCALLS.

3. Only use wire-up semtimeop iff __NR_semtimedop is also defined.
  

On 10/05/2019 12:07, Adhemerval Zanella wrote:
> 
> 
> On 10/05/2019 07:27, Stepan Golosunov wrote:
>> 09.05.2019 в 23:00:37 +0000 Joseph Myers написал:
>>> Linux 5.1 adds missing syscalls to the syscall table for many Linux
>>> kernel architectures.  This patch updates the kernel-features.h
>>> headers accordingly.  I believe the statfs64 structure used by alpha
>>> matches what the new kernel syscalls use, but that should be reviewed
>>> carefully.
>>>
>>> Tested with build-many-glibcs.py.
>>
>> The newly added direct ipc syscalls are different from the old ones:
>>
>> 1. They do not accept IPC_64.  This means that __IPC_64 should be set
>> to zero when new syscalls are used.  And new syscalls can not be used
>> for compat functions like __old_semctl.
> 
> So it seems we will need to conditionally set __IPC_64 based on kernel
> version. It also seems that our default value on generic ipc_priv.h
> is not really expressing the kernel ABI.
> 
>>
>> (Hmm.  Is __old_msgctl already buggy due to its use of __IPC_64 when
>> __ASSUME_DIRECT_SYSVIPC_SYSCALLS is defined?  Is there any
>> architecture with both __ASSUME_DIRECT_SYSVIPC_SYSCALLS and
>> __old_msgctl currently?)
> 
> The architectures that exports msgctl@GLIBC_2.0 as compat symbol are
> alpha, i686, m68k, mips-o32, powerpc32, s390-32, and sparc32. And
> from these one alpha currently is the only architecture that defines
> __ASSUME_DIRECT_SYSVIPC_SYSCALLS. So it is buggy for alpha currently
> and it would be for the aforementioned architectures once they
> start to use wire-up syscall.
> 
> 
>>
>> 2. semtimedop does not exist on 32-bit ABIs.  They have
>> semtimedop_time64 instead.
>> (I also think that ipc with IPCOP_semtimedop was accidentally made to
>> behave like semtimedop_time64 in 32-bit builds of linux 5.1.  But that
>> would be a kernel bug.)
> 
> So it seems we would need to either add an __ASSUME specific for semtimedop
> to just enable wire-up calls if time64 is defined or add another pre-processor
> check to see if __NR_semtimeop is defined as well.
> 
> 
> To summarize, I think we need too:
> 
> 1. Fix Linux msgctl compat function to remove __IPC64.
> 
> 2. Move __IPC64 to kernel-feature.h and define it based on kernel version
>    along with __ASSUME_DIRECT_SYSVIPC_SYSCALLS.
> 
> 3. Only use wire-up semtimeop iff __NR_semtimedop is also defined.
> 

It seems semop would also need be handled this way.
  

10.05.2019 в 12:11:22 -0300 Adhemerval Zanella написал:
> On 10/05/2019 12:07, Adhemerval Zanella wrote:
> > On 10/05/2019 07:27, Stepan Golosunov wrote:
> >> 09.05.2019 в 23:00:37 +0000 Joseph Myers написал:
> >>> Linux 5.1 adds missing syscalls to the syscall table for many Linux
> >>> kernel architectures.  This patch updates the kernel-features.h
> >>> headers accordingly.  I believe the statfs64 structure used by alpha
> >>> matches what the new kernel syscalls use, but that should be reviewed
> >>> carefully.
> >>>
> >>> Tested with build-many-glibcs.py.
> >>
> >> The newly added direct ipc syscalls are different from the old ones:
> >>
> >> 1. They do not accept IPC_64.  This means that __IPC_64 should be set
> >> to zero when new syscalls are used.  And new syscalls can not be used
> >> for compat functions like __old_semctl.
> > 
> > So it seems we will need to conditionally set __IPC_64 based on kernel
> > version. It also seems that our default value on generic ipc_priv.h
> > is not really expressing the kernel ABI.
> > 
> >>
> >> (Hmm.  Is __old_msgctl already buggy due to its use of __IPC_64 when
> >> __ASSUME_DIRECT_SYSVIPC_SYSCALLS is defined?  Is there any
> >> architecture with both __ASSUME_DIRECT_SYSVIPC_SYSCALLS and
> >> __old_msgctl currently?)
> > 
> > The architectures that exports msgctl@GLIBC_2.0 as compat symbol are
> > alpha, i686, m68k, mips-o32, powerpc32, s390-32, and sparc32. And
> > from these one alpha currently is the only architecture that defines
> > __ASSUME_DIRECT_SYSVIPC_SYSCALLS. So it is buggy for alpha currently
> > and it would be for the aforementioned architectures once they
> > start to use wire-up syscall.
> > 
> > 
> >>
> >> 2. semtimedop does not exist on 32-bit ABIs.  They have
> >> semtimedop_time64 instead.
> >> (I also think that ipc with IPCOP_semtimedop was accidentally made to
> >> behave like semtimedop_time64 in 32-bit builds of linux 5.1.  But that
> >> would be a kernel bug.)
> > 
> > So it seems we would need to either add an __ASSUME specific for semtimedop
> > to just enable wire-up calls if time64 is defined or add another pre-processor
> > check to see if __NR_semtimeop is defined as well.
> > 
> > 
> > To summarize, I think we need too:
> > 
> > 1. Fix Linux msgctl compat function to remove __IPC64.
> > 
> > 2. Move __IPC64 to kernel-feature.h and define it based on kernel version
> >    along with __ASSUME_DIRECT_SYSVIPC_SYSCALLS.
> > 
> > 3. Only use wire-up semtimeop iff __NR_semtimedop is also defined.
> > 
> 
> It seems semop would also need be handled this way.

5. Ensure __old_msgctl, __old_semctl and __old_shmctl do not use
direct syscalls when __IPC64 is zero.
  

On 10/05/2019 13:15, Stepan Golosunov wrote:
> 10.05.2019 в 12:11:22 -0300 Adhemerval Zanella написал:
>> On 10/05/2019 12:07, Adhemerval Zanella wrote:
>>> On 10/05/2019 07:27, Stepan Golosunov wrote:
>>>> 09.05.2019 в 23:00:37 +0000 Joseph Myers написал:
>>>>> Linux 5.1 adds missing syscalls to the syscall table for many Linux
>>>>> kernel architectures.  This patch updates the kernel-features.h
>>>>> headers accordingly.  I believe the statfs64 structure used by alpha
>>>>> matches what the new kernel syscalls use, but that should be reviewed
>>>>> carefully.
>>>>>
>>>>> Tested with build-many-glibcs.py.
>>>>
>>>> The newly added direct ipc syscalls are different from the old ones:
>>>>
>>>> 1. They do not accept IPC_64.  This means that __IPC_64 should be set
>>>> to zero when new syscalls are used.  And new syscalls can not be used
>>>> for compat functions like __old_semctl.
>>>
>>> So it seems we will need to conditionally set __IPC_64 based on kernel
>>> version. It also seems that our default value on generic ipc_priv.h
>>> is not really expressing the kernel ABI.
>>>
>>>>
>>>> (Hmm.  Is __old_msgctl already buggy due to its use of __IPC_64 when
>>>> __ASSUME_DIRECT_SYSVIPC_SYSCALLS is defined?  Is there any
>>>> architecture with both __ASSUME_DIRECT_SYSVIPC_SYSCALLS and
>>>> __old_msgctl currently?)
>>>
>>> The architectures that exports msgctl@GLIBC_2.0 as compat symbol are
>>> alpha, i686, m68k, mips-o32, powerpc32, s390-32, and sparc32. And
>>> from these one alpha currently is the only architecture that defines
>>> __ASSUME_DIRECT_SYSVIPC_SYSCALLS. So it is buggy for alpha currently
>>> and it would be for the aforementioned architectures once they
>>> start to use wire-up syscall.
>>>
>>>
>>>>
>>>> 2. semtimedop does not exist on 32-bit ABIs.  They have
>>>> semtimedop_time64 instead.
>>>> (I also think that ipc with IPCOP_semtimedop was accidentally made to
>>>> behave like semtimedop_time64 in 32-bit builds of linux 5.1.  But that
>>>> would be a kernel bug.)
>>>
>>> So it seems we would need to either add an __ASSUME specific for semtimedop
>>> to just enable wire-up calls if time64 is defined or add another pre-processor
>>> check to see if __NR_semtimeop is defined as well.
>>>
>>>
>>> To summarize, I think we need too:
>>>
>>> 1. Fix Linux msgctl compat function to remove __IPC64.
>>>
>>> 2. Move __IPC64 to kernel-feature.h and define it based on kernel version
>>>    along with __ASSUME_DIRECT_SYSVIPC_SYSCALLS.
>>>
>>> 3. Only use wire-up semtimeop iff __NR_semtimedop is also defined.
>>>
>>
>> It seems semop would also need be handled this way.
> 
> 5. Ensure __old_msgctl, __old_semctl and __old_shmctl do not use
> direct syscalls when __IPC64 is zero.

Indeed, alpha cases prevents us to just use __NR_ipc in this case.
  

On Fri, May 10, 2019 at 3:19 PM Stepan Golosunov <stepan@golosunov.pp.ru> wrote:
>
> 10.05.2019 в 14:27:13 +0400 Stepan Golosunov написал(а):
> > 09.05.2019 в 23:00:37 +0000 Joseph Myers написал:
> > > Linux 5.1 adds missing syscalls to the syscall table for many Linux
> > > kernel architectures.  This patch updates the kernel-features.h
> > > headers accordingly.  I believe the statfs64 structure used by alpha
> > > matches what the new kernel syscalls use, but that should be reviewed
> > > carefully.
> > >
> > > Tested with build-many-glibcs.py.
> >
> > The newly added direct ipc syscalls are different from the old ones:
> >
> > 1. They do not accept IPC_64.  This means that __IPC_64 should be set
> > to zero when new syscalls are used.  And new syscalls can not be used
> > for compat functions like __old_semctl.

Correct, the idea is that we can stop passing that flag on most architectures
when a C library only supports new kernels.

I expect that glibc will start using the direct system calls in 5 to 10 years,
once it stops running on linux-5.0 and earlier. Until then, the easiest way
is to keep using the ipc() wrapper.

> > (Hmm.  Is __old_msgctl already buggy due to its use of __IPC_64 when
> > __ASSUME_DIRECT_SYSVIPC_SYSCALLS is defined?  Is there any
> > architecture with both __ASSUME_DIRECT_SYSVIPC_SYSCALLS and
> > __old_msgctl currently?)

My spreadsheet [1] tells me that mips-n32, mips-n64, alpha, arm, microblaze
and xtensa all provide the direct syscalls traditionally but require passing
__IPC_64 for historic reasons. Out of these, only arm-oabi (no longer supported
in glibc) also has sys_ipc().
It would have been nice to change that, but it seemed not worth adding another
set of IPC syscalls for these.

> > 2. semtimedop does not exist on 32-bit ABIs.  They have
> > semtimedop_time64 instead.

Right, we had a long debate over that, and in the end I decided not to
add two versions of semtimedop() to keep the ABI more compact.

> > (I also think that ipc with IPCOP_semtimedop was accidentally made to
> > behave like semtimedop_time64 in 32-bit builds of linux 5.1.  But that
> > would be a kernel bug.)

Can you elaborate? The code I see in mainline is

        case SEMTIMEDOP:
                if (IS_ENABLED(CONFIG_64BIT) || !IS_ENABLED(CONFIG_64BIT_TIME))
                        return ksys_semtimedop(first, ptr, second,
                                (const struct __kernel_timespec __user *)fifth);
                else if (IS_ENABLED(CONFIG_COMPAT_32BIT_TIME))
                        return compat_ksys_semtimedop(first, ptr, second,
                                (const struct old_timespec32 __user *)fifth);
                else
                        return -ENOSYS;

Since both CONFIG_64BIT_TIME and CONFIG_COMPAT_32BIT_TIME
are always set on 32-bit architectures, SEMTIMEDOP passes
an old_timespec32 argument here. Am I missing something?

> And, after rereading
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0d6040d4681735dfc47565de288525de405a5c99
>
> 3. There is no semop. semtimedop(_time64)? should be used instead.

Right.

      Arnd

[1] https://docs.google.com/spreadsheets/d/1QxMvW5jpVG2jb4RM9CQQl27-wVpNYOa-_3K2RVKifb0/edit#gid=0
  

On Fri, May 10, 2019 at 5:07 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 10/05/2019 07:27, Stepan Golosunov wrote:
> > 09.05.2019 в 23:00:37 +0000 Joseph Myers написал:
> >> Linux 5.1 adds missing syscalls to the syscall table for many Linux
> >> kernel architectures.  This patch updates the kernel-features.h
> >> headers accordingly.  I believe the statfs64 structure used by alpha
> >> matches what the new kernel syscalls use, but that should be reviewed
> >> carefully.
> >>
> >> Tested with build-many-glibcs.py.
> >
> > The newly added direct ipc syscalls are different from the old ones:
> >
> > 1. They do not accept IPC_64.  This means that __IPC_64 should be set
> > to zero when new syscalls are used.  And new syscalls can not be used
> > for compat functions like __old_semctl.
>
> So it seems we will need to conditionally set __IPC_64 based on kernel
> version.

How so? I did not expect to see any libc change here at all, unless
you mean after you stop using sys_ipc().

> It also seems that our default value on generic ipc_priv.h
> is not really expressing the kernel ABI.

Right, it should only be set for historic ABIs.

> > 2. semtimedop does not exist on 32-bit ABIs.  They have
> > semtimedop_time64 instead.
> > (I also think that ipc with IPCOP_semtimedop was accidentally made to
> > behave like semtimedop_time64 in 32-bit builds of linux 5.1.  But that
> > would be a kernel bug.)
>
> So it seems we would need to either add an __ASSUME specific for semtimedop
> to just enable wire-up calls if time64 is defined or add another pre-processor
> check to see if __NR_semtimeop is defined as well.

The implementation I expected to see here is to have the
64-bit time_t version of semtimedop() to call the direct semtimedop_time64()
system call, and fall back to the existing implementation if that
returns -ENOSYS and the libc is built to support old kernels.

        Arnd
  

On 16/05/2019 05:08, Arnd Bergmann wrote:
> On Fri, May 10, 2019 at 5:07 PM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>> On 10/05/2019 07:27, Stepan Golosunov wrote:
>>> 09.05.2019 в 23:00:37 +0000 Joseph Myers написал:
>>>> Linux 5.1 adds missing syscalls to the syscall table for many Linux
>>>> kernel architectures.  This patch updates the kernel-features.h
>>>> headers accordingly.  I believe the statfs64 structure used by alpha
>>>> matches what the new kernel syscalls use, but that should be reviewed
>>>> carefully.
>>>>
>>>> Tested with build-many-glibcs.py.
>>>
>>> The newly added direct ipc syscalls are different from the old ones:
>>>
>>> 1. They do not accept IPC_64.  This means that __IPC_64 should be set
>>> to zero when new syscalls are used.  And new syscalls can not be used
>>> for compat functions like __old_semctl.
>>
>> So it seems we will need to conditionally set __IPC_64 based on kernel
>> version.
> 
> How so? I did not expect to see any libc change here at all, unless
> you mean after you stop using sys_ipc().

The idea is if user configure a minimum kernel version of v5.1,
sysvipc would use wire-up syscalls.  So for sys_ipc the affected
architectures calls with required IPC_64, and for wire-up syscalls
IPC_64 is redefined accordingly. 

> 
>> It also seems that our default value on generic ipc_priv.h
>> is not really expressing the kernel ABI.
> 
> Right, it should only be set for historic ABIs.
> 
>>> 2. semtimedop does not exist on 32-bit ABIs.  They have
>>> semtimedop_time64 instead.
>>> (I also think that ipc with IPCOP_semtimedop was accidentally made to
>>> behave like semtimedop_time64 in 32-bit builds of linux 5.1.  But that
>>> would be a kernel bug.)
>>
>> So it seems we would need to either add an __ASSUME specific for semtimedop
>> to just enable wire-up calls if time64 is defined or add another pre-processor
>> check to see if __NR_semtimeop is defined as well.
> 
> The implementation I expected to see here is to have the
> 64-bit time_t version of semtimedop() to call the direct semtimedop_time64()
> system call, and fall back to the existing implementation if that
> returns -ENOSYS and the libc is built to support old kernels.

I am not taking in consideration 64-bit time_t adjustments here.
  

On Thu, May 16, 2019 at 1:15 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 16/05/2019 05:08, Arnd Bergmann wrote:
> > On Fri, May 10, 2019 at 5:07 PM Adhemerval Zanella
> > <adhemerval.zanella@linaro.org> wrote:
> >> On 10/05/2019 07:27, Stepan Golosunov wrote:
> >>> 09.05.2019 в 23:00:37 +0000 Joseph Myers написал:
> >>>> Linux 5.1 adds missing syscalls to the syscall table for many Linux
> >>>> kernel architectures.  This patch updates the kernel-features.h
> >>>> headers accordingly.  I believe the statfs64 structure used by alpha
> >>>> matches what the new kernel syscalls use, but that should be reviewed
> >>>> carefully.
> >>>>
> >>>> Tested with build-many-glibcs.py.
> >>>
> >>> The newly added direct ipc syscalls are different from the old ones:
> >>>
> >>> 1. They do not accept IPC_64.  This means that __IPC_64 should be set
> >>> to zero when new syscalls are used.  And new syscalls can not be used
> >>> for compat functions like __old_semctl.
> >>
> >> So it seems we will need to conditionally set __IPC_64 based on kernel
> >> version.
> >
> > How so? I did not expect to see any libc change here at all, unless
> > you mean after you stop using sys_ipc().
>
> The idea is if user configure a minimum kernel version of v5.1,
> sysvipc would use wire-up syscalls.  So for sys_ipc the affected
> architectures calls with required IPC_64, and for wire-up syscalls
> IPC_64 is redefined accordingly.

Ah, I see. Is there any real advantage in doing this now though?
It seems to save a few cycles for each of those syscalls when building
for linux-5.1+, but the cost is a significant increase in source code
complexity.

      Arnd
  

On 16/05/2019 08:34, Arnd Bergmann wrote:
> On Thu, May 16, 2019 at 1:15 PM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>> On 16/05/2019 05:08, Arnd Bergmann wrote:
>>> On Fri, May 10, 2019 at 5:07 PM Adhemerval Zanella
>>> <adhemerval.zanella@linaro.org> wrote:
>>>> On 10/05/2019 07:27, Stepan Golosunov wrote:
>>>>> 09.05.2019 в 23:00:37 +0000 Joseph Myers написал:
>>>>>> Linux 5.1 adds missing syscalls to the syscall table for many Linux
>>>>>> kernel architectures.  This patch updates the kernel-features.h
>>>>>> headers accordingly.  I believe the statfs64 structure used by alpha
>>>>>> matches what the new kernel syscalls use, but that should be reviewed
>>>>>> carefully.
>>>>>>
>>>>>> Tested with build-many-glibcs.py.
>>>>>
>>>>> The newly added direct ipc syscalls are different from the old ones:
>>>>>
>>>>> 1. They do not accept IPC_64.  This means that __IPC_64 should be set
>>>>> to zero when new syscalls are used.  And new syscalls can not be used
>>>>> for compat functions like __old_semctl.
>>>>
>>>> So it seems we will need to conditionally set __IPC_64 based on kernel
>>>> version.
>>>
>>> How so? I did not expect to see any libc change here at all, unless
>>> you mean after you stop using sys_ipc().
>>
>> The idea is if user configure a minimum kernel version of v5.1,
>> sysvipc would use wire-up syscalls.  So for sys_ipc the affected
>> architectures calls with required IPC_64, and for wire-up syscalls
>> IPC_64 is redefined accordingly.
> 
> Ah, I see. Is there any real advantage in doing this now though?
> It seems to save a few cycles for each of those syscalls when building
> for linux-5.1+, but the cost is a significant increase in source code
> complexity.

Not really, however it gave me opportunity to clean up the sysvipc code a bit
more. I changed the __IPC_64 default value to 0x0, which simplifies a bit
new ports additions (no need to override the value); consolidates some
implementation a bit more (s390 is an outlier regarding semtimedop); and
we spot an compat issues on alpha.

I am just checking everthing is ok on a 5.1 kernel before send it to
review.
  

On Thu, May 16, 2019 at 2:28 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 16/05/2019 08:34, Arnd Bergmann wrote:
> > On Thu, May 16, 2019 at 1:15 PM Adhemerval Zanella
> > <adhemerval.zanella@linaro.org> wrote:
> >> On 16/05/2019 05:08, Arnd Bergmann wrote:
> >>> On Fri, May 10, 2019 at 5:07 PM Adhemerval Zanella
> >>> How so? I did not expect to see any libc change here at all, unless
> >>> you mean after you stop using sys_ipc().
> >>
> >> The idea is if user configure a minimum kernel version of v5.1,
> >> sysvipc would use wire-up syscalls.  So for sys_ipc the affected
> >> architectures calls with required IPC_64, and for wire-up syscalls
> >> IPC_64 is redefined accordingly.
> >
> > Ah, I see. Is there any real advantage in doing this now though?
> > It seems to save a few cycles for each of those syscalls when building
> > for linux-5.1+, but the cost is a significant increase in source code
> > complexity.
>
> Not really, however it gave me opportunity to clean up the sysvipc code a bit
> more. I changed the __IPC_64 default value to 0x0, which simplifies a bit
> new ports additions (no need to override the value); consolidates some
> implementation a bit more (s390 is an outlier regarding semtimedop); and
> we spot an compat issues on alpha.

Ok, fair enough. Too bad this didn't come up during the review of
the kernel patches, I could probably have kept the IPC_64 flag
for the separate calls on mips/alpha/arm/microblaze/xtensa to make
it easier for you.

      Arnd
  

16.05.2019 в 09:59:40 +0200 Arnd Bergmann написал:
> On Fri, May 10, 2019 at 3:19 PM Stepan Golosunov <stepan@golosunov.pp.ru> wrote:
> > > (I also think that ipc with IPCOP_semtimedop was accidentally made to
> > > behave like semtimedop_time64 in 32-bit builds of linux 5.1.  But that
> > > would be a kernel bug.)
> 
> Can you elaborate? The code I see in mainline is
> 
>         case SEMTIMEDOP:
>                 if (IS_ENABLED(CONFIG_64BIT) || !IS_ENABLED(CONFIG_64BIT_TIME))
>                         return ksys_semtimedop(first, ptr, second,
>                                 (const struct __kernel_timespec __user *)fifth);
>                 else if (IS_ENABLED(CONFIG_COMPAT_32BIT_TIME))
>                         return compat_ksys_semtimedop(first, ptr, second,
>                                 (const struct old_timespec32 __user *)fifth);
>                 else
>                         return -ENOSYS;
> 
> Since both CONFIG_64BIT_TIME and CONFIG_COMPAT_32BIT_TIME
> are always set on 32-bit architectures, SEMTIMEDOP passes
> an old_timespec32 argument here. Am I missing something?

If CONFIG_64BIT_TIME is set then there is no problem.  But I do not
see where it is set.  (The patch to set it to y was merged only now
and is not in 5.1.)  And if it's not set, then ipc and socketcall are
broken.
  

On Thu, May 16, 2019 at 9:41 PM Stepan Golosunov <stepan@golosunov.pp.ru> wrote:
>
> 16.05.2019 в 09:59:40 +0200 Arnd Bergmann написал:
> > On Fri, May 10, 2019 at 3:19 PM Stepan Golosunov <stepan@golosunov.pp.ru> wrote:
> > > > (I also think that ipc with IPCOP_semtimedop was accidentally made to
> > > > behave like semtimedop_time64 in 32-bit builds of linux 5.1.  But that
> > > > would be a kernel bug.)
> >
> > Can you elaborate? The code I see in mainline is
> >
> >         case SEMTIMEDOP:
> >                 if (IS_ENABLED(CONFIG_64BIT) || !IS_ENABLED(CONFIG_64BIT_TIME))
> >                         return ksys_semtimedop(first, ptr, second,
> >                                 (const struct __kernel_timespec __user *)fifth);
> >                 else if (IS_ENABLED(CONFIG_COMPAT_32BIT_TIME))
> >                         return compat_ksys_semtimedop(first, ptr, second,
> >                                 (const struct old_timespec32 __user *)fifth);
> >                 else
> >                         return -ENOSYS;
> >
> > Since both CONFIG_64BIT_TIME and CONFIG_COMPAT_32BIT_TIME
> > are always set on 32-bit architectures, SEMTIMEDOP passes
> > an old_timespec32 argument here. Am I missing something?
>
> If CONFIG_64BIT_TIME is set then there is no problem.  But I do not
> see where it is set.  (The patch to set it to y was merged only now
> and is not in 5.1.)  And if it's not set, then ipc and socketcall are
> broken.

Oh, I see it now. So the bug was actually much worse than I thought, since
we did not enable CONFIG_64BIT_TIME at all, only
CONFIG_COMPAT_32BIT_TIME. I assumed that only the nanosecond
mangling in compat mode was broken.

The problem is that in commit 00bf25d693e7 ("y2038: use time32 syscall
names on 32-bit"), I turned on CONFIG_COMPAT_32BIT_TIME
unconditionally, when I should have turned on CONFIG_64BIT_TIME
or ARCH_HAS_64BIT_TIME instead.

So indeed both ipc(SEMTIMEDOP, ...) and socketcall(SYS_RECVMMSG, ...)
are broken in linux-5.1 with 32-bit architectures. My testing failed to
catch those because I used a musl libc as a base that was already using
semtimedop() and recvmmsg() as direct syscalls, and those are not
affected.

The fix has made it into mainline now for v5.2-rc1, but not yet v5.1.y.

Greg, can you add this commit for the next v5.1.y stable kernel to
fix the regression?

f3d964673b2f ("y2038: Make CONFIG_64BIT_TIME unconditional")

      Arnd