Missing time64 prototypes for !__REDIRECT compilers

Missing time64 prototypes for !__REDIRECT compilers

[Florian Weimer]

This pattern looks incorrect to me:

#ifdef __USE_GNU
/* Receive up to VLEN messages as described by VMESSAGES from socket FD.
   Returns the number of messages received or -1 for errors.

   This function is a cancellation point and therefore not marked with
   __THROW.  */
# ifndef __USE_TIME_BITS64
extern int recvmmsg (int __fd, struct mmsghdr *__vmessages,
		     unsigned int __vlen, int __flags,
		     struct timespec *__tmo);
# else
#  ifdef __REDIRECT
extern int __REDIRECT (recvmmsg, (int __fd, struct mmsghdr *__vmessages,
                                  unsigned int __vlen, int __flags,
                                  struct timespec *__tmo),
                       __recvmmsg64);
#  else
#   define recvmmsg __recvmmsg64
#  endif
# endif
#endif

For the !__REDIRECT case, a prototype for __recvmmsg64 is still needed.

Thanks,
Florian

Re: Missing time64 prototypes for !__REDIRECT compilers

[Adhemerval Zanella]

On 05/07/2021 06:48, Florian Weimer wrote:
> This pattern looks incorrect to me:
> 
> #ifdef __USE_GNU
> /* Receive up to VLEN messages as described by VMESSAGES from socket FD.
>    Returns the number of messages received or -1 for errors.
> 
>    This function is a cancellation point and therefore not marked with
>    __THROW.  */
> # ifndef __USE_TIME_BITS64
> extern int recvmmsg (int __fd, struct mmsghdr *__vmessages,
> 		     unsigned int __vlen, int __flags,
> 		     struct timespec *__tmo);
> # else
> #  ifdef __REDIRECT
> extern int __REDIRECT (recvmmsg, (int __fd, struct mmsghdr *__vmessages,
>                                   unsigned int __vlen, int __flags,
>                                   struct timespec *__tmo),
>                        __recvmmsg64);
> #  else
> #   define recvmmsg __recvmmsg64
> #  endif
> # endif
> #endif
> 
> For the !__REDIRECT case, a prototype for __recvmmsg64 is still needed.

There is some fixes for recvmsg and recvmmsg that I am working on,
I will add this as well.

Re: Missing time64 prototypes for !__REDIRECT compilers

[Florian Weimer]

* Adhemerval Zanella:

> On 05/07/2021 06:48, Florian Weimer wrote:
>> This pattern looks incorrect to me:
>> 
>> #ifdef __USE_GNU
>> /* Receive up to VLEN messages as described by VMESSAGES from socket FD.
>>    Returns the number of messages received or -1 for errors.
>> 
>>    This function is a cancellation point and therefore not marked with
>>    __THROW.  */
>> # ifndef __USE_TIME_BITS64
>> extern int recvmmsg (int __fd, struct mmsghdr *__vmessages,
>> 		     unsigned int __vlen, int __flags,
>> 		     struct timespec *__tmo);
>> # else
>> #  ifdef __REDIRECT
>> extern int __REDIRECT (recvmmsg, (int __fd, struct mmsghdr *__vmessages,
>>                                   unsigned int __vlen, int __flags,
>>                                   struct timespec *__tmo),
>>                        __recvmmsg64);
>> #  else
>> #   define recvmmsg __recvmmsg64
>> #  endif
>> # endif
>> #endif
>> 
>> For the !__REDIRECT case, a prototype for __recvmmsg64 is still needed.
>
> There is some fixes for recvmsg and recvmmsg that I am working on,
> I will add this as well.

I'm working on adding some missing time64 aliases.  I've got a
SCM_RIGHTS smoke test.

Thanks,
Florian

Re: Missing time64 prototypes for !__REDIRECT compilers

[Adhemerval Zanella]

On 05/07/2021 09:15, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 05/07/2021 06:48, Florian Weimer wrote:
>>> This pattern looks incorrect to me:
>>>
>>> #ifdef __USE_GNU
>>> /* Receive up to VLEN messages as described by VMESSAGES from socket FD.
>>>    Returns the number of messages received or -1 for errors.
>>>
>>>    This function is a cancellation point and therefore not marked with
>>>    __THROW.  */
>>> # ifndef __USE_TIME_BITS64
>>> extern int recvmmsg (int __fd, struct mmsghdr *__vmessages,
>>> 		     unsigned int __vlen, int __flags,
>>> 		     struct timespec *__tmo);
>>> # else
>>> #  ifdef __REDIRECT
>>> extern int __REDIRECT (recvmmsg, (int __fd, struct mmsghdr *__vmessages,
>>>                                   unsigned int __vlen, int __flags,
>>>                                   struct timespec *__tmo),
>>>                        __recvmmsg64);
>>> #  else
>>> #   define recvmmsg __recvmmsg64
>>> #  endif
>>> # endif
>>> #endif
>>>
>>> For the !__REDIRECT case, a prototype for __recvmmsg64 is still needed.
>>
>> There is some fixes for recvmsg and recvmmsg that I am working on,
>> I will add this as well.
> 
> I'm working on adding some missing time64 aliases.  I've got a
> SCM_RIGHTS smoke test.

Do you mean for recvmg/recvmmsg? If so do we really need these? I fixed
an issue on __convert_scm_timestamps that I think it the most likely
issue that trigger the invalid memory access on ruby testcase.

Re: Missing time64 prototypes for !__REDIRECT compilers

[Florian Weimer]

* Adhemerval Zanella:

> On 05/07/2021 09:15, Florian Weimer wrote:
>> * Adhemerval Zanella:
>> 
>>> On 05/07/2021 06:48, Florian Weimer wrote:
>>>> This pattern looks incorrect to me:
>>>>
>>>> #ifdef __USE_GNU
>>>> /* Receive up to VLEN messages as described by VMESSAGES from socket FD.
>>>>    Returns the number of messages received or -1 for errors.
>>>>
>>>>    This function is a cancellation point and therefore not marked with
>>>>    __THROW.  */
>>>> # ifndef __USE_TIME_BITS64
>>>> extern int recvmmsg (int __fd, struct mmsghdr *__vmessages,
>>>> 		     unsigned int __vlen, int __flags,
>>>> 		     struct timespec *__tmo);
>>>> # else
>>>> #  ifdef __REDIRECT
>>>> extern int __REDIRECT (recvmmsg, (int __fd, struct mmsghdr *__vmessages,
>>>>                                   unsigned int __vlen, int __flags,
>>>>                                   struct timespec *__tmo),
>>>>                        __recvmmsg64);
>>>> #  else
>>>> #   define recvmmsg __recvmmsg64
>>>> #  endif
>>>> # endif
>>>> #endif
>>>>
>>>> For the !__REDIRECT case, a prototype for __recvmmsg64 is still needed.
>>>
>>> There is some fixes for recvmsg and recvmmsg that I am working on,
>>> I will add this as well.
>> 
>> I'm working on adding some missing time64 aliases.  I've got a
>> SCM_RIGHTS smoke test.
>
> Do you mean for recvmg/recvmmsg? If so do we really need these? I fixed
> an issue on __convert_scm_timestamps that I think it the most likely
> issue that trigger the invalid memory access on ruby testcase.

I have identified the following system calls:

ioctl, fcntl, prctl, sendmmsg, recvmsg, sendmsg, getsockopt, setsockopt.

All of them are multiplexers of some kind, and we don't know if the
kernel will add different constants for different time_t sizes for
future features, given that it's more or less 64-bit time_t only these
days.

Thanks,
Florian

Re: Missing time64 prototypes for !__REDIRECT compilers

[Adhemerval Zanella]

On 05/07/2021 09:42, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 05/07/2021 09:15, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> On 05/07/2021 06:48, Florian Weimer wrote:
>>>>> This pattern looks incorrect to me:
>>>>>
>>>>> #ifdef __USE_GNU
>>>>> /* Receive up to VLEN messages as described by VMESSAGES from socket FD.
>>>>>    Returns the number of messages received or -1 for errors.
>>>>>
>>>>>    This function is a cancellation point and therefore not marked with
>>>>>    __THROW.  */
>>>>> # ifndef __USE_TIME_BITS64
>>>>> extern int recvmmsg (int __fd, struct mmsghdr *__vmessages,
>>>>> 		     unsigned int __vlen, int __flags,
>>>>> 		     struct timespec *__tmo);
>>>>> # else
>>>>> #  ifdef __REDIRECT
>>>>> extern int __REDIRECT (recvmmsg, (int __fd, struct mmsghdr *__vmessages,
>>>>>                                   unsigned int __vlen, int __flags,
>>>>>                                   struct timespec *__tmo),
>>>>>                        __recvmmsg64);
>>>>> #  else
>>>>> #   define recvmmsg __recvmmsg64
>>>>> #  endif
>>>>> # endif
>>>>> #endif
>>>>>
>>>>> For the !__REDIRECT case, a prototype for __recvmmsg64 is still needed.
>>>>
>>>> There is some fixes for recvmsg and recvmmsg that I am working on,
>>>> I will add this as well.
>>>
>>> I'm working on adding some missing time64 aliases.  I've got a
>>> SCM_RIGHTS smoke test.
>>
>> Do you mean for recvmg/recvmmsg? If so do we really need these? I fixed
>> an issue on __convert_scm_timestamps that I think it the most likely
>> issue that trigger the invalid memory access on ruby testcase.
> 
> I have identified the following system calls:
> 
> ioctl, fcntl, prctl, sendmmsg, recvmsg, sendmsg, getsockopt, setsockopt.
> 
> All of them are multiplexers of some kind, and we don't know if the
> kernel will add different constants for different time_t sizes for
> future features, given that it's more or less 64-bit time_t only these
> days.

But kernel afaik uses the time_t size to provide such constant, if it
adds a new 64-bit time_t only it won't build for _TIME_BITS=32.

Re: Missing time64 prototypes for !__REDIRECT compilers

[Florian Weimer]

* Adhemerval Zanella:

>> I have identified the following system calls:
>> 
>> ioctl, fcntl, prctl, sendmmsg, recvmsg, sendmsg, getsockopt, setsockopt.
>> 
>> All of them are multiplexers of some kind, and we don't know if the
>> kernel will add different constants for different time_t sizes for
>> future features, given that it's more or less 64-bit time_t only these
>> days.
>
> But kernel afaik uses the time_t size to provide such constant, if it
> adds a new 64-bit time_t only it won't build for _TIME_BITS=32.

Sorry, I don't understand what this means in this context.

I am worried that the kernel will add a new fcntl which expectes a
64-bit struct timespec argument.  Without the 64-bit state in the glibc
symbol, glibc would not know whether to rewrite the argument or not for
32-bit applications.

Thanks,
Florian

Re: Missing time64 prototypes for !__REDIRECT compilers

[Adhemerval Zanella]

On 05/07/2021 09:50, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>>> I have identified the following system calls:
>>>
>>> ioctl, fcntl, prctl, sendmmsg, recvmsg, sendmsg, getsockopt, setsockopt.
>>>
>>> All of them are multiplexers of some kind, and we don't know if the
>>> kernel will add different constants for different time_t sizes for
>>> future features, given that it's more or less 64-bit time_t only these
>>> days.
>>
>> But kernel afaik uses the time_t size to provide such constant, if it
>> adds a new 64-bit time_t only it won't build for _TIME_BITS=32.
> 
> Sorry, I don't understand what this means in this context.
> 
> I am worried that the kernel will add a new fcntl which expectes a
> 64-bit struct timespec argument.  Without the 64-bit state in the glibc
> symbol, glibc would not know whether to rewrite the argument or not for
> 32-bit applications.

My point I expected the kernel to add such new fcntl interface (or for any
other multiplexed interfaces) only for 'sizeof(time_t) == sizeof(__kernel_time64_t)'
which means that programs built with _TIME_SIZE=32 won't see such newer
constants.