[PATCH rtems-libbsd 1/7] rtemsbsd: Catch timeout overflows

Chris Johns chrisj at rtems.org
Wed Jul 28 06:43:20 UTC 2021


On 28/7/21 4:03 pm, Sebastian Huber wrote:
> On 28/07/2021 00:53, Chris Johns wrote:
>> On 28/7/21 7:38 am, Gedare Bloom wrote:
>>> On Tue, Jul 27, 2021 at 2:59 AM<chrisj at rtems.org>  wrote:
>>>> From: Chris Johns<chrisj at rtems.org>
>>>>
>>>> Update #4475
>>> This change could probably use its own ticket.
>> Without the change the RPC client fails to connect in a reliable way because the
>> connection may time out for no real reason. A connection that is stable appears
>> fragile. I used this ticket because the change was needed for NFS to work.
>>
>> https://github.com/freebsd/freebsd-src/blob/main/sys/rpc/clnt_dg.c#L388
>>
>>>> ---
>>>>   rtemsbsd/rtems/rtems-kernel-timesupport.c | 8 +++++++-
>>>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/rtemsbsd/rtems/rtems-kernel-timesupport.c
>>>> b/rtemsbsd/rtems/rtems-kernel-timesupport.c
>>>> index ef14d1fa..5d290d66 100644
>>>> --- a/rtemsbsd/rtems/rtems-kernel-timesupport.c
>>>> +++ b/rtemsbsd/rtems/rtems-kernel-timesupport.c
>>>> @@ -35,6 +35,7 @@
>>>>
>>>>   #include <machine/rtems-bsd-kernel-space.h>
>>>>
>>>> +#include <limits.h>
>>>>   #include <sys/time.h>
>>>>
>>>>   #include <rtems/score/timespec.h>
>>>> @@ -46,9 +47,14 @@ int
>>>>   tvtohz(struct timeval *tv)
>>>>   {
>>>>     struct timespec ts;
>>>> +  uint32_t ticks;
>>>>
>>>>     ts.tv_sec = tv->tv_sec;
>>>>     ts.tv_nsec = tv->tv_usec * 1000;
>>>>
>>>> -  return (int) _Timespec_To_ticks( &ts );
>>>> +  ticks = _Timespec_To_ticks( &ts );
>>>> +  if (ticks > INT_MAX)
>>>> +    ticks = INT_MAX;
>>>> +
>>> This changes the behavior to saturating in the overflow case, which is
>>> at least well-defined, but is it the best thing to do?  (I have no
>>> idea.)
>> I do not have a better suggestion? The user is providing a timeval that exceeds
>> the size of the return value so providing the max value at least the gets you
>> closer to the actual value than any other value?
> 
> Why don't we use the FreeBSD implementation one-to-one:
> 
> freebsd-org/sys/kern/kern_clock.c
> 

I am fixing the code that exists. I have no idea why kern_clock.c was not ported
in the first place. I will not be porting the clock code at this point in time,
that is out of scope for my current work.

Chris


More information about the devel mailing list