On 28/7/21 7:38 am, Gedare Bloom wrote: > On Tue, Jul 27, 2021 at 2:59 AM <chr...@rtems.org> wrote: >> >> From: Chris Johns <chr...@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? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
