On 04/05/2020 12:26, Lukasz Majewski wrote:
> Hi Adhemerval,
> 
>> On 01/05/2020 08:30, Lukasz Majewski wrote:
>>> Hi Adhemerval,
>>>   
>>>> On 26/03/2020 05:06, Lukasz Majewski wrote:  
>>>>> The nscd/nscd_helper.c uses __clock_gettime to get current time
>>>>> and on this basis calculate the relative timeout for poll.
>>>>> By using __clock_gettime64 on systems with __WORDSIZE == 32 &&
>>>>> __TIMESIZE != 64 the timeout is correctly calculated after time_t
>>>>> overflow.    
>>>>
>>>> LGTM, thanks.
>>>>  
>>>>> ---
>>>>>  nscd/nscd_helper.c | 17 +++++++++--------
>>>>>  1 file changed, 9 insertions(+), 8 deletions(-)
>>>>>
>>>>> diff --git a/nscd/nscd_helper.c b/nscd/nscd_helper.c
>>>>> index d2d7d15f26..a4f3312f90 100644
>>>>> --- a/nscd/nscd_helper.c
>>>>> +++ b/nscd/nscd_helper.c
>>>>> @@ -37,6 +37,7 @@
>>>>>  #include <not-cancel.h>
>>>>>  #include <kernel-features.h>
>>>>>  #include <nss.h>
>>>>> +#include <struct___timespec64.h>
>>>>>  
>>>>>  #include "nscd-client.h"
>>>>>  
>>>>> @@ -59,10 +60,10 @@ wait_on_socket (int sock, long int usectmo)
>>>>>        /* Handle the case where the poll() call is interrupted by
>>>>> a signal.  We cannot just use TEMP_FAILURE_RETRY since it
>>>>> might lead to infinite loops.  */
>>>>> -      struct timespec now;
>>>>> -      __clock_gettime (CLOCK_REALTIME, &now);
>>>>> -      long int end = (now.tv_sec * 1000 + usectmo
>>>>> -                      + (now.tv_nsec + 500000) / 1000000);
>>>>> +      struct __timespec64 now;
>>>>> +      __clock_gettime64 (CLOCK_REALTIME, &now);
>>>>> +      int64_t end = (now.tv_sec * 1000 + usectmo
>>>>> +                     + (now.tv_nsec + 500000) / 1000000);
>>>>>        long int timeout = usectmo;
>>>>>        while (1)
>>>>>  	{    
>>>>
>>>> Ok. Maybe we could use ppoll instead here to simplify the timeout
>>>> calculation?
>>>>  
>>>
>>> I wanted to change as little as possible (to not introduce any extra
>>> bugs) to only replace __clock_gettime with __clock_gettime64.   
>>
>> I don't have a strong opinion here, it is just that it might
>> simplifies a bit the timeout handling.
> 
> If you don't mind I would prefer to change as little as possible and
> stick to the approach (changes) proposed in this patch.
> 
> Do you agree with such approach?

Ack.