Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756206AbbFVJsi (ORCPT ); Mon, 22 Jun 2015 05:48:38 -0400 Received: from mout.gmx.net ([212.227.17.22]:62207 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754581AbbFVJs3 (ORCPT ); Mon, 22 Jun 2015 05:48:29 -0400 Message-ID: <5587D9DA.6000102@gmx.at> Date: Mon, 22 Jun 2015 11:48:10 +0200 From: Manfred Schlaegl User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Oliver Hartkopp , Wolfgang Grandegger , Marc Kleine-Budde CC: linux-can@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Manfred Schlaegl , "David S. Miller" Subject: Re: [PATCH] can: fix loss of frames due to wrong assumption in raw_rcv References: <5585A104.1090201@gmx.at> <5585EC4D.40103@hartkopp.net> In-Reply-To: <5585EC4D.40103@hartkopp.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:R/Dm/fnsM+yO14XDvqnBmsHSrZinmYoySFbUEd7IOzEnhmujIPz B+OIN1WOVqj0kg2NH0aMmro3behOr6Nz1Zi9t62lntuquYDTtiJ7Mw6Y1+xOc50NofRisNI RsjFClw+4rEPgOhgyqtkbuVYrdMqbsP4sGyzOvDIho1xmB0UyPYCRhSbHK8gPWf4VwOPD0+ fVzLCOo6RALZzm40ccrng== X-UI-Out-Filterresults: notjunk:1;V01:K0:cxNPH3d74Tc=:qZhhwAsoKxJk2JJn70GfP1 vh8iJYt2Ea5b6qD9SPCN4kBHOD+p/do9Buo7gxw0sT64J5hb3H/jH3sp7fMJxxnd0jRGQF/0J s/3Ysz/v1YcbAymbd6+Z6vMYiO/K9zM+tkIR5vdPMX6Im//38tcODe5B3g9tc3aRmLoADh/Aj cucp6fqEy13QOmyL9FD3Jndn4VL0v/2/SMeHNv/s2vrYhHSi+qzMJ9Poq+yzPm6IuLA/ro5m6 rwGflBSfF5sV6KKXF3iNbn77NiYjuFba9htt8e0cGG9LN9gGO2yhSORbY9KttE+JcbIiU4zu3 +nZEGmYav8Gl+z7EW3mh6RiJs+ujOzUGZjsSF7YTqoNchUjcLBSYdREhuj1LBDI40ZGa2hcZI SxF9ciqBfl++Stss9C0NTMR7snodL1nRLl6mLr7/GbZlm0QtP1gIFt80pucXwR7FZY+Ii5Ow0 0PFEdk/Od+r6TRgRW+XGHblDD/9LnNhh4ydul6ZTYrcvE6v/8EKWBDwuBT7Sf/N+khxKq00Oe 6V+czB1l4y3qxIOj7I7YrerDLyHs6tQc6eOLAOXOOjQjac0ZlJWRwigEQuA13RyW+LgH9M8OO Z7OsG34Bk3aQtsrrcizVd0TffKcdorQwOTRcyWXUq3PXjZA60gN0hVeSCbgd6uSM32pA9h3Z5 qd33uPUmFYCr3yY/iefbMR4u9xnnpfBCQn1RQ1Zgs0oZfxCy3gozqbOXFqIiQ9OQ5hOY= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2912 Lines: 62 Hello Oliver, On 2015-06-21 00:42, Oliver Hartkopp wrote: >> 514ac99c64b22d83b52dfee3b8becaa69a92bc4a introduces a frame equality >> check. Since the sk_buff pointer is not sufficient to do this (buffers >> are reused), the check also compares time stamps. >> In short: pointer+time stamp was assumed as unique key to a specific >> frame. >> The problem with this is, that the time stamp is an optional property >> and not set per default. >> In our case (flexcan) the time stamp is always zero, so the equality >> check is reduced to equality of buffer pointers, resulting in a lot of >> dropped frames. > > The question is why your system did not generate a timestamp at the time of > skb reception. > > Usually when netif_rx(), netif_rx_ni() is invoked the timestamp is set in the > following reception process. > > flexcan.c only uses netif_receive_skb() - but all theses functions set the > timestamp > > net_timestamp_check(netdev_tstamp_prequeue, skb); > > depending on netdev_tstamp_prequeue which is configured by > > /proc/sys/net/core/netdev_tstamp_prequeue > > See the idea of netdev_tstamp_prequeue here: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/core/sysctl_net_core.c?id=3b098e2d7c693796cc4dffb07caa249fc0f70771 > Thank you for the background information! I've also noticed your patch [PATCH - regression 4.1-rc8] can: fix loss of CAN frames in raw_rcv > Can you tell me the output of /proc/sys/net/core/netdev_tstamp_prequeue on > your machine? /proc/sys/net/core/netdev_tstamp_prequeue is set to 1 (unmodified, default) I tried to dig a little deeper in timestamping: 1. (net/core/dev.c) I found that static_key_false(&netstamp_needed) is always 0, resulting that the timestamp is never set by net_timestamp_check in netif_receive_skb_internal. 2. (net/core/dev.c) static_key_false(&netstamp_needed) is 0 because net_enable_timestamp is never called. 3. (net/core/sock.c) net_enable_timestamp is never called because SK_FLAGS_TIMESTAMP is not set 4. (net/core/sock.c) SK_FLAGS_TIMESTAMP is not set because neither of SOCK_TIMESTAMP or SOCK_TIMESTAMPING_RX_SOFTWARE is set 5. (net/core/sock.c) SOCK_TIMESTAMP or SOCK_TIMESTAMPING_RX_SOFTWARE is not set because timestamping is an optional feature (according to http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/timestamping.txt?id=b953c0d234bc72e8489d3bf51a276c5c4ec85345) not enabled in my use case (even if netdev_tstamp_prequeue is set to 1) So the original assumption for the was correct: The correctness of the skb equality check depends on a feature that is not enabled by default (respectively user configurable). Do you agree with this? > > Thanks again for your investigation! Sure! Best regards, Manfred -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/