netdev - Re: [PATCH - regression 4.1-rc8] can: fix loss of CAN frames in raw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 22 Jun 2015 17:09:29 +0200
From:	Oliver Hartkopp <socketcan@...tkopp.net>
To:	Manfred Schlaegl <manfred.schlaegl@....at>, netdev@...r.kernel.org,
	davem@...emloft.net, linux-kernel@...r.kernel.org,
	mkl@...gutronix.de
Subject: Re: [PATCH - regression 4.1-rc8] can: fix loss of CAN frames in raw_rcv

On 22.06.2015 13:49, Manfred Schlaegl wrote:
> On 2015-06-22 12:34, Oliver Hartkopp wrote:
>> On 22.06.2015 12:10, Manfred Schlaegl wrote:
>>> Hypothetical example: If timestamping is enabled by the user and there is a significant delay between allocation and delivery of a skb (early allocation in driver or something) the timestamp does not reflect the reception time anymore.
>>
>> The change only affects CAN skbs.
>> These skbs are allocated at CAN frame reception time, filled with content and then sent to the network layer.
>>
>> AFAICS the timestamp becomes more precise for CAN related skbs.
>> I did not see any case of 'early allocation' in linux/drivers/net/can, did you?
>
> No, I also did not find this case in current driver implementations -- because of that I gave the hypothetical example.
> I just was worried about that this may be a potential latent issue for future driver implementations and wanted to indicate this.
>
> But I trust your expertise, so if you are fine with it, I'm too. ;-)

I don't claim to be 'an expert' :-)

But our usual use-case is CAN logging which enables the timestamping on all 
CAN interfaces anyway - without any problems.

As the timestamp is calculated only once this patch moves the timestamp 
creation closer to the CAN frame arrival time - so latency finally decreases.

Best regards,
Oliver

--
To unsubscribe from this list: send the line "unsubscribe netdev" in