Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1378357pxu; Fri, 16 Oct 2020 10:25:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxE65oOZk+ceJxlCeOx0rMuTL9q6nmLeDXULhQ2stNdT2COWADEd8RPSjFMozv/GfCPB43W X-Received: by 2002:a50:fe13:: with SMTP id f19mr5302200edt.178.1602869122764; Fri, 16 Oct 2020 10:25:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602869122; cv=none; d=google.com; s=arc-20160816; b=SM3azLVSs0b8OHOyaDWlKJ0Pwtij4rJk2DwN6bZMrUzYz2uFrlR0i3zDxiN7sUgAz9 tM/N4YhtWnxhk1iszpUFbtBsyQfXFkBAcLT5DCguqqsPdzsXPote3mDul1z2NfVLnLsK VwiotvbH5RNQiWPxl8ojtFs03Wk2sZpx7XFPTtaOMS7eSsyOVQwYpE+YQTTG4kxHCbiQ 1X7qQnebgpY6SXfGc4t9VZeYAxQXDMCczVgwNg01oTIpC/Jhjsu45AQmqu7nocdRDOTL op+A2Im2cPSLQgO6eKND7L6+5j70oK9T9dHnsxAQzfQt1QlcKUnl2pjzKZRPVYC4pK1K 9qyQ== 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=GYaDUtlTOtbsP3SkPUHcwOv3JpScOIipRtOjk5y7luc=; b=y/9JAfF7BFRXnm/6qV4mVvNPCbCmB/fvCDs8gMrlrMT/JOVmwRGaECIiFtF71tff06 3aYTSEIDSe93KZV9vjIOaaQ8PfYajthMsKMlYIcLHJ7RTDE7QL3rnV/bnzV9HsxGvvjp a/u598w5lqBQ+ZwaUB1lMHYLWxwpa+S4o4lf/mD/g5tFk/E/LGjMA/IQvJBtuH0bRNFM mrQohlEvIcA5eXWdEYEpcq7BQbct2n3L5J8sOnc2cDLQT0uEw5GGeQRG3f5KhlUvutkG jhBl1viwr6DFJZy3m8gRzoKRGnPB1rtxTpE1E9KCQBXL4YgCJUTYykWCzvaxJ/EJj9l4 JM2w== 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 cy8si2141749edb.527.2020.10.16.10.25.00; Fri, 16 Oct 2020 10:25:22 -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 S2390353AbgJPRV3 (ORCPT + 99 others); Fri, 16 Oct 2020 13:21:29 -0400 Received: from smtp09.smtpout.orange.fr ([80.12.242.131]:47170 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390433AbgJPRV3 (ORCPT ); Fri, 16 Oct 2020 13:21:29 -0400 Received: from tomoyo.flets-east.jp ([153.230.197.127]) by mwinf5d44 with ME id ghMB2300J2lQRaH03hML2a; Fri, 16 Oct 2020 19:21:26 +0200 X-ME-Helo: tomoyo.flets-east.jp X-ME-Auth: bWFpbGhvbC52aW5jZW50QHdhbmFkb28uZnI= X-ME-Date: Fri, 16 Oct 2020 19:21:26 +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, Marc Kleine-Budde , Wolfgang Grandegger Cc: Arunachalam Santhanam , Vincent Mailhol , "David S. Miller" , Jakub Kicinski , Masahiro Yamada Subject: [PATCH v4 2/4] can: dev: add a helper function to get the correct length of Classical frames Date: Sat, 17 Oct 2020 02:20:23 +0900 Message-Id: <20201016172053.229281-1-mailhol.vincent@wanadoo.fr> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20201016171402.229001-1-mailhol.vincent@wanadoo.fr> References: <20201016171402.229001-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 --- Changes in v4: None Changes in v3: - Make get_can_len() return u8. - Make the skb const. Reference: https://lkml.org/lkml/2020/9/30/883 Changes in v2: None --- 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 41ff31795320..d90890172d2a 100644 --- a/include/linux/can/dev.h +++ b/include/linux/can/dev.h @@ -192,6 +192,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 u8 get_can_len(const struct sk_buff *skb) +{ + const struct canfd_frame *cf = (const 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