On 1/13/19 9:18 AM, Oliver Hartkopp wrote:
> Hi Andre,
>
> On 1/12/19 11:45 PM, Andre Naujoks wrote:
>> I really don't know. That's why I'd be hesitant to restrict this. Maybe
>> limit it to something really out of the ordinary, like a year?
>
> :-)
>
> The intention was to send and monitor cycl
Hi Andre,
On 1/12/19 11:45 PM, Andre Naujoks wrote:
I really don't know. That's why I'd be hesitant to restrict this. Maybe
limit it to something really out of the ordinary, like a year?
:-)
The intention was to send and monitor cyclic CAN frames within a range
of 5 to 5000ms. Even if you wa
I really don't know. That's why I'd be hesitant to restrict this. Maybe
limit it to something really out of the ordinary, like a year?
I am not sure that for example one hour would be out of the question for
some edge cases. Maybe someone wants to do a heartbeat for his/her
system with a very low
Hi Andre,
just wondered whether it makes sense to limit this value for sending
cyclic messages or for detecting a timeout on reception.
4.294.967.295 seconds would be ~136 years - this makes no sense to me
and I would assume someone applied some (unintended?) stuff into the
timeval.
Don't
Hi.
The 15 minute limit seems arbitrary to me. I'd be surprised if an
(R|T)X_SETUP failed because of a timeout greater than this. Are there
any problems with allowing larger timeouts? If not, I do not see a
reason to restrict this.
Regards
Andre
On 1/12/19 10:57 PM, Oliver Hartkopp wrote:
> Ky
Kyungtae Kim detected a potential integer overflow in bcm_[rx|tx]_setup() when
the conversion into ktime multiplies the given value with NSEC_PER_USEC (1000).
Reference: https://marc.info/?l=linux-can&m=154732118819828&w=2
Add a check for the given tv_usec, so that the value stays below one secon
