timex: Use 64-bit fields on 32-bit TIMESIZE=64 systems

  This was found when testing the OpenRISC port I am working on.  These
two tests fail with SIGSEGV:

  FAIL: misc/tst-ntp_gettime
  FAIL: misc/tst-ntp_gettimex

This was found to be due to the kernel overwriting the stack space
allocated by the timex structure.  The reason for the overwrite being
that the kernel timex has 64-bit fields and user space code only
allocates enough stack space for timex with 32-bit fields.

On 32-bit systems with TIMESIZE=64 __USE_TIME_BITS64 is not defined.
This causes the timex structure to use 32-bit fields with type
__syscall_slong_t.

This patch adjusts the ifdef condition to allow 32-bit systems with
TIMESIZE=64 to use the 64-bit long long timex definition.
---
 sysdeps/unix/sysv/linux/bits/timex.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

On 14/10/2021 18:17, Stafford Horne via Libc-alpha wrote:
> This was found when testing the OpenRISC port I am working on.  These
> two tests fail with SIGSEGV:
> 
>   FAIL: misc/tst-ntp_gettime
>   FAIL: misc/tst-ntp_gettimex
> 
> This was found to be due to the kernel overwriting the stack space
> allocated by the timex structure.  The reason for the overwrite being
> that the kernel timex has 64-bit fields and user space code only
> allocates enough stack space for timex with 32-bit fields.
> 
> On 32-bit systems with TIMESIZE=64 __USE_TIME_BITS64 is not defined.
> This causes the timex structure to use 32-bit fields with type
> __syscall_slong_t.> 
> This patch adjusts the ifdef condition to allow 32-bit systems with
> TIMESIZE=64 to use the 64-bit long long timex definition.

Why is this not an issue for arc or riscv32? Both are 32-bit architectures
have default 64-bit time_t.

This changes all current 32-bit architectures with default 64-bit time_t
and I not sure if this break something (or if the interface is already
broken).  I will try to check on riscv32.


> ---
>  sysdeps/unix/sysv/linux/bits/timex.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sysdeps/unix/sysv/linux/bits/timex.h b/sysdeps/unix/sysv/linux/bits/timex.h
> index ee37694e8f..4a5db6deca 100644
> --- a/sysdeps/unix/sysv/linux/bits/timex.h
> +++ b/sysdeps/unix/sysv/linux/bits/timex.h
> @@ -25,7 +25,7 @@
>  
>  struct timex
>  {
> -# ifdef __USE_TIME_BITS64
> +# if defined __USE_TIME_BITS64 || (__TIMESIZE == 64 && __WORDSIZE == 32)
>    unsigned int modes;          /* mode selector */
>    int :32;                     /* pad */
>    long long offset;            /* time offset (usec) */
>
  

On 18/10/2021 14:29, Adhemerval Zanella wrote:
> 
> 
> On 14/10/2021 18:17, Stafford Horne via Libc-alpha wrote:
>> This was found when testing the OpenRISC port I am working on.  These
>> two tests fail with SIGSEGV:
>>
>>   FAIL: misc/tst-ntp_gettime
>>   FAIL: misc/tst-ntp_gettimex
>>
>> This was found to be due to the kernel overwriting the stack space
>> allocated by the timex structure.  The reason for the overwrite being
>> that the kernel timex has 64-bit fields and user space code only
>> allocates enough stack space for timex with 32-bit fields.
>>
>> On 32-bit systems with TIMESIZE=64 __USE_TIME_BITS64 is not defined.
>> This causes the timex structure to use 32-bit fields with type
>> __syscall_slong_t.> 
>> This patch adjusts the ifdef condition to allow 32-bit systems with
>> TIMESIZE=64 to use the 64-bit long long timex definition.
> 
> Why is this not an issue for arc or riscv32? Both are 32-bit architectures
> have default 64-bit time_t.
> 
> This changes all current 32-bit architectures with default 64-bit time_t
> and I not sure if this break something (or if the interface is already
> broken).  I will try to check on riscv32.

So master is broken on riscv32 (both misc/tst-ntp_gettime and 
misc/tst-ntp_gettimex aborts) and I guess it is on arc as well.

On Linux side, the clock_adjtime syscall (kernel/time/posix-timers.c:1112)
which maps to __NR_clock_gettime64 on 32-bit with legacy 32-bit and
__NR_clock_gettime otherwise always use __kernel_timex.

The patch looks ok and we will need to backport it as well.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

> 
> 
>> ---
>>  sysdeps/unix/sysv/linux/bits/timex.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/sysdeps/unix/sysv/linux/bits/timex.h b/sysdeps/unix/sysv/linux/bits/timex.h
>> index ee37694e8f..4a5db6deca 100644
>> --- a/sysdeps/unix/sysv/linux/bits/timex.h
>> +++ b/sysdeps/unix/sysv/linux/bits/timex.h
>> @@ -25,7 +25,7 @@
>>  
>>  struct timex
>>  {
>> -# ifdef __USE_TIME_BITS64
>> +# if defined __USE_TIME_BITS64 || (__TIMESIZE == 64 && __WORDSIZE == 32)
>>    unsigned int modes;          /* mode selector */
>>    int :32;                     /* pad */
>>    long long offset;            /* time offset (usec) */
>>
  

On Mon, 18 Oct 2021, Adhemerval Zanella via Libc-alpha wrote:

> So master is broken on riscv32 (both misc/tst-ntp_gettime and 
> misc/tst-ntp_gettimex aborts) and I guess it is on arc as well.
> 
> On Linux side, the clock_adjtime syscall (kernel/time/posix-timers.c:1112)
> which maps to __NR_clock_gettime64 on 32-bit with legacy 32-bit and
> __NR_clock_gettime otherwise always use __kernel_timex.
> 
> The patch looks ok and we will need to backport it as well.

If it's broken for existing architectures in a release, there should be a 
bug filed in Bugzilla if not already present, then marked RESOLVED/FIXED 
with target milestone set to 2.35 once the fix is pushed so that the fix 
appears in the generated list of fixed bugs in NEWS.
  

On 18/10/2021 16:35, Joseph Myers wrote:
> On Mon, 18 Oct 2021, Adhemerval Zanella via Libc-alpha wrote:
> 
>> So master is broken on riscv32 (both misc/tst-ntp_gettime and 
>> misc/tst-ntp_gettimex aborts) and I guess it is on arc as well.
>>
>> On Linux side, the clock_adjtime syscall (kernel/time/posix-timers.c:1112)
>> which maps to __NR_clock_gettime64 on 32-bit with legacy 32-bit and
>> __NR_clock_gettime otherwise always use __kernel_timex.
>>
>> The patch looks ok and we will need to backport it as well.
> 
> If it's broken for existing architectures in a release, there should be a 
> bug filed in Bugzilla if not already present, then marked RESOLVED/FIXED 
> with target milestone set to 2.35 once the fix is pushed so that the fix 
> appears in the generated list of fixed bugs in NEWS.
> 

I created https://sourceware.org/bugzilla/show_bug.cgi?id=28469