From: Wolfram Sang <w.sang@pengutronix.de>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Kurt Van Dijck <kurt.van.dijck@eia.be>, linux-can@vger.kernel.org
Subject: Re: Truncate DLC to 8 instead of dropping?
Date: Sat, 1 Sep 2012 19:33:13 +0200 [thread overview]
Message-ID: <20120901173313.GA9656@pengutronix.de> (raw)
In-Reply-To: <5040E7C2.4040305@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]
On Fri, Aug 31, 2012 at 06:35:14PM +0200, Oliver Hartkopp wrote:
> Hello Kurt and Wolfram,
>
> On 31.08.2012 14:50, Kurt Van Dijck wrote:
>
> > On Fri, Aug 31, 2012 at 01:59:04PM +0200, Wolfram Sang wrote:
> >> Hi,
> >>
> >> I just noticed today that commit c7cd606f60e7679c7f9eee7010f02a6f000209c1
> >> ("can: Fix data length code handling in rx path") says regarding
> >> overlong packets:
> >>
> >> ===
> >>
> >> The ISO 11898-1 Chapter 8.4.2.3 (DLC field) says that register values > 8
> >> should be reduced to 8 without any error reporting or frame drop.
> >>
> >> ===
> >>
> >> and this is why get_can_dlc() came into existance.
> >>
> >> However, functions like can_dropped_invalid_skb() from dev.h or can_rcv() from
> >> af_can.c do check for a correct length, but drop the packet in the error case.
> >> Don't those need to be fixed?
> >>
> >
> > Interesting point. My first idea is to acknowledge your thinking, BUT:
> > * ISO 11898-1 is about the wire format, whereas your issues address
> > higher level interfaces. Higher level interfaces may IMHO use a stricter
> > format that the wire format.
>
>
> Pointing to the wire format is a good idea.
> To me this "dlc error ignoring" requirement is implemented by the CAN
> controller. And when the dlc value in the controller register is not sanitized
> we should do it on driver level.
If I understand both of you correctly, that means the checks in the
functions I mentioned should be removed then?
Fine with me if this is consistent, I just wondered if it wasn't nice to
have a check in an upper layer in case the driver did not correctly
implement the check.
Thanks,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2012-09-01 17:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-31 11:59 Truncate DLC to 8 instead of dropping? Wolfram Sang
2012-08-31 12:50 ` Kurt Van Dijck
2012-08-31 16:35 ` Oliver Hartkopp
2012-09-01 17:33 ` Wolfram Sang [this message]
2012-09-01 18:11 ` Kurt Van Dijck
2012-09-01 18:17 ` Wolfram Sang
2012-09-01 19:27 ` Oliver Hartkopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120901173313.GA9656@pengutronix.de \
--to=w.sang@pengutronix.de \
--cc=kurt.van.dijck@eia.be \
--cc=linux-can@vger.kernel.org \
--cc=socketcan@hartkopp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.