Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp4630357pxk; Wed, 30 Sep 2020 07:52:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwoNo0lMQ4pQhRQJM2y+LTsU4yx5T9Z+xewBMGGqdiNfv5HaLzOCME09rKl2an8dxgzq7Lj X-Received: by 2002:a17:906:e113:: with SMTP id gj19mr3228299ejb.263.1601477565488; Wed, 30 Sep 2020 07:52:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601477565; cv=none; d=google.com; s=arc-20160816; b=zeQ6EaKogy06rjLheAte3SmBnAz+yyNRSeiq3wpgq6zMlYRpJcTIOGxtk+1q5UJi+K EZdNAur/dEX6eN5TyYJgWSpbn7fjbc3ClH83VYLi3bL1Jp1RvhoszWIdx3X1X3ZgT4Ue g9g/itOb6Mj7TV/jCAsfq32ke0y1X3OfVKDWvnZ9ZaO2Ukg4Tb95HLeKhaeCFu5eBZIo 68ORjKWi3PCIYr2fEgPi32huSvqYyU5TfqL5DwldZaJDGtIr2OJgYH4er+f4j/zaMDfN t1HS2Z+lF6ZIOJp6glQTZOmmMHtd/2xLBA4ec150tK+xVqebU8ki47oM2w5dRMmffYTG td9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=ItAdSh3XC/91k55+wY06eo2kGE04swYsiQQw+VK4t4c=; b=hVz1bsrIDegJzshvlSZojAMrrExuEIpwBgPlwwVDnn0se0l6P4mSuOX5uodXwkJU5T /q/PUJYwLKDkIME7a4aDnRhd5wwGp3ihWE4+aQy4wOgblU5oobUs082st6Hy+UQnVqiT 7Y7afI4YYw1ME8TzvEIC00eJWcgoVdi+kOBkRygQEm467mPDaBDGc7dDpFj+kbpJ70FR WZ+2bRcs19LjTwdo9k7CtmsfW/XtZmMn4kggiYwgtISfZR4A4tik89csFo8q30c1WgAj /Qivg79MdvNPRFLxI3Nh9GOckS0Q+amX/8lFLeTFGXGTIttdDEQ0X0re5IBOoV5MhKZ7 T7aQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j23si1350339ejm.736.2020.09.30.07.52.21; Wed, 30 Sep 2020 07:52:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728149AbgI3OvR (ORCPT + 99 others); Wed, 30 Sep 2020 10:51:17 -0400 Received: from smtp09.smtpout.orange.fr ([80.12.242.131]:35712 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730107AbgI3OvQ (ORCPT ); Wed, 30 Sep 2020 10:51:16 -0400 Received: from tomoyo.flets-east.jp ([153.230.197.127]) by mwinf5d69 with ME id aEqx2300T2lQRaH03Er8kM; Wed, 30 Sep 2020 16:51:15 +0200 X-ME-Helo: tomoyo.flets-east.jp X-ME-Auth: bWFpbGhvbC52aW5jZW50QHdhbmFkb28uZnI= X-ME-Date: Wed, 30 Sep 2020 16:51:15 +0200 X-ME-IP: 153.230.197.127 From: Vincent Mailhol To: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-can@vger.kernel.org, Wolfgang Grandegger , Marc Kleine-Budde , "David S . Miller" Cc: Vincent Mailhol , Jakub Kicinski , Oliver Neukum , Greg Kroah-Hartman , Masahiro Yamada , Arunachalam Santhanam , linux-usb@vger.kernel.org (open list:USB ACM DRIVER) Subject: [PATCH v2 2/6] can: dev: add a helper function to get the correct length of Classical frames Date: Wed, 30 Sep 2020 23:45:29 +0900 Message-Id: <20200930144602.10290-3-mailhol.vincent@wanadoo.fr> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200926175810.278529-1-mailhol.vincent@wanadoo.fr> References: <20200926175810.278529-1-mailhol.vincent@wanadoo.fr> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In classical CAN, the length of the data (i.e. CAN payload) is not always equal to the DLC! If the frame is a Remote Transmission Request (RTR), data length is always zero regardless of DLC value and else, if the DLC is greater than 8, the length is 8. Contrary to common belief, ISO 11898-1 Chapter 8.4.2.3 (DLC field) do allow DLCs greater than 8 for Classical Frames and specifies that those DLCs shall indicate that the data field is 8 bytes long. Above facts are widely unknown and so many developpers uses the "len" field of "struct canfd_frame" to get the length of classical CAN frames: this is incorrect! This patch introduces function get_can_len() which can be used in remediation. The function takes the SKB as an input in order to be able to determine if the frame is classical or FD. Signed-off-by: Vincent Mailhol --- include/linux/can/dev.h | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h index 5e3d45525bd3..72a8a60c0094 100644 --- a/include/linux/can/dev.h +++ b/include/linux/can/dev.h @@ -177,6 +177,29 @@ u8 can_dlc2len(u8 can_dlc); /* map the sanitized data length to an appropriate data length code */ u8 can_len2dlc(u8 len); +/* + * get_can_len(skb) - get the length of the CAN payload. + * + * In classical CAN, the length of the data (i.e. CAN payload) is not + * always equal to the DLC! If the frame is a Remote Transmission + * Request (RTR), data length is always zero regardless of DLC value + * and else, if the DLC is greater than 8, the length is 8. Contrary + * to common belief, ISO 11898-1 Chapter 8.4.2.3 (DLC field) do allow + * DLCs greater than 8 for Classical Frames and specifies that those + * DLCs shall indicate that the data field is 8 bytes long. + */ +static inline int get_can_len(struct sk_buff *skb) +{ + struct canfd_frame *cf = (struct canfd_frame *)skb->data; + + if (can_is_canfd_skb(skb)) + return min_t(__u8, cf->len, CANFD_MAX_DLEN); + else if (cf->can_id & CAN_RTR_FLAG) + return 0; + else + return min_t(__u8, cf->len, CAN_MAX_DLEN); +} + struct net_device *alloc_candev_mqs(int sizeof_priv, unsigned int echo_skb_max, unsigned int txqs, unsigned int rxqs); #define alloc_candev(sizeof_priv, echo_skb_max) \ -- 2.26.2