Re: [PATCH rtems-libbsd 1/7] rtemsbsd: Catch timeout overflows
On 29/7/21 8:44 am, Chris Johns wrote: > On 28/7/21 4:44 pm, Sebastian Huber wrote: >> On 28/07/2021 08:43, Chris Johns wrote: 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. >> >> What I meant was to copy the tvtohz() from kern_clock.c to this file. > > Ah ok, sure I can take a look. The only difference is some extra checks and if there is value in having those checks they should be added to the cpukit. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 1/7] rtemsbsd: Catch timeout overflows
On 28/7/21 4:44 pm, Sebastian Huber wrote: > On 28/07/2021 08:43, Chris Johns wrote: >>> 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. > > What I meant was to copy the tvtohz() from kern_clock.c to this file. Ah ok, sure I can take a look. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 1/7] rtemsbsd: Catch timeout overflows
On 28/07/2021 08:43, Chris Johns wrote: 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. What I meant was to copy the tvtohz() from kern_clock.c to this file. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 1/7] rtemsbsd: Catch timeout overflows
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 wrote:
From: Chris Johns
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
+#include
#include
#include
@@ -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( );
+ ticks = _Timespec_To_ticks( );
+ 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 1/7] rtemsbsd: Catch timeout overflows
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 wrote:
From: Chris Johns
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
+#include
#include
#include
@@ -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( );
+ ticks = _Timespec_To_ticks( );
+ 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
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 1/7] rtemsbsd: Catch timeout overflows
On 28/7/21 7:38 am, Gedare Bloom wrote:
> On Tue, Jul 27, 2021 at 2:59 AM wrote:
>>
>> From: Chris Johns
>>
>> 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
>>
>> +#include
>> #include
>>
>> #include
>> @@ -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( );
>> + ticks = _Timespec_To_ticks( );
>> + 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
Re: [PATCH rtems-libbsd 1/7] rtemsbsd: Catch timeout overflows
On Tue, Jul 27, 2021 at 2:59 AM wrote:
>
> From: Chris Johns
>
> Update #4475
This change could probably use its own ticket.
> ---
> 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
>
> +#include
> #include
>
> #include
> @@ -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( );
> + ticks = _Timespec_To_ticks( );
> + 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.)
> + return ticks;
> }
> --
> 2.24.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
