Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1743358rwb; Sat, 19 Nov 2022 02:43:27 -0800 (PST) X-Google-Smtp-Source: AA0mqf5QsocKH1XNz17PkwegOP7IIuFgZoGaqCVWJZdwpYAQvtcukQK1vkf9pixgSXgDAt6pPc2Z X-Received: by 2002:a05:6a00:1825:b0:56c:f16d:2f29 with SMTP id y37-20020a056a00182500b0056cf16d2f29mr12041808pfa.53.1668854607617; Sat, 19 Nov 2022 02:43:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668854607; cv=none; d=google.com; s=arc-20160816; b=jcDk1Q1Q2e20+jLVetU/wJkfQY5HuJCi3v44DbYChWi4GuXc//ksZjLUPG+YwfsZq5 e05wgcfRzheJqiv5wrhoC/SVRm8QQTrbhA3mksNM09mFUASFs4Mis5g5KrPi+tShe8uU +EkmlZPgolnQdzJOQH60Eq/B1Rr4PiF9+yTsK6/O28iB4ki6ojBM7Hdwvquki4vIoSOh cF30M/+bC/lzVdpyMpKI0gm8VOwL0MjmrlU1FbUYDhNSSNQJyuVt4si9hfZJsTSTZCHy OCByPXIaWja6d1LX20C3C+I4ofd11azmgJn2YPWpk2wnzwkSahu152dvOZ8cmKHiRxkX /mkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=1EVuPERo6ns5ab0uJlG/ohcHa+5RQD68bCvfCHZjfy8=; b=lH1rthYi8Vl7z/W0kPBYUgKEmTulCFGsOG2q3a3PZjMZU+UCKQLYocQ3VdSpE2U7PB SSjIw7KgD2LBs9KdLcycskiB+erEqQ9o3oN3bSJ2fjrUIOAlCP6/FZX7U9wb2hF4lOyX +zth3kKnm4M4C2W9AwxEdwWvGqRj+N8jkJu4tqlmqduWs/7xK89sVkwCCOWc/CpvzVG7 UWd67g4eqpo+nFPbcMWX99Xjir29axM5wXsO83enMv2PameFHKmOt9AWaqryZnYWl8Pz OPEMbem0tPqtLJAIpufoouwEERxVeTGUbGKYLmU/bauhGUQhxBTIdpu7fv9JOLcy7gnc RrVg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d8-20020a170902b70800b00176953fee67si5443168pls.86.2022.11.19.02.43.15; Sat, 19 Nov 2022 02:43:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231717AbiKSKMj (ORCPT + 91 others); Sat, 19 Nov 2022 05:12:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45034 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229470AbiKSKMh (ORCPT ); Sat, 19 Nov 2022 05:12:37 -0500 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C7E326AEF9 for ; Sat, 19 Nov 2022 02:12:35 -0800 (PST) Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1owKpe-0007kV-V0; Sat, 19 Nov 2022 11:12:18 +0100 Received: from ore by ptx.hi.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1owKpX-00043P-IH; Sat, 19 Nov 2022 11:12:11 +0100 Date: Sat, 19 Nov 2022 11:12:11 +0100 From: Oleksij Rempel To: Devid Antonio Filoni Cc: Oliver Hartkopp , Kurt Van Dijck , kbuild test robot , Maxime Jayat , Robin van der Gracht , linux-kernel@vger.kernel.org, Oleksij Rempel , Paolo Abeni , Marc Kleine-Budde , kernel@pengutronix.de, David Jander , Jakub Kicinski , netdev@vger.kernel.org, linux-can@vger.kernel.org, "David S. Miller" Subject: Re: [PATCH RESEND] can: j1939: do not wait 250ms if the same addr was already claimed Message-ID: <20221119101211.GA7626@pengutronix.de> References: <20220511162247.2cf3fb2e@erd992> <3566cba652c64641603fd0ad477e2c90cd77655b.camel@egluetechnologies.com> <20221117162251.5e5933c1@erd992> <20221118060647.GE12278@pengutronix.de> <7b575cface09a2817ac53485507985a7fef7b835.camel@egluetechnologies.com> <20221118123013.GF12278@pengutronix.de> <1fd663d232c7fba5f956faf1ad45fb410a675086.camel@egluetechnologies.com> <20221118134447.GG12278@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-Accept-Language: de,en X-Accept-Content-Type: text/plain User-Agent: Mutt/1.10.1 (2018-07-13) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: ore@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 18, 2022 at 04:12:40PM +0100, Devid Antonio Filoni wrote: > Hi Oleksij, > > honestly I would apply proposed patch because it is the easier solution > and makes the driver compliant with the standard for the following > reasons: > - on the first claim, the kernel will wait 250 ms as stated by the > standard > + on successive claims with the same name, the kernel will not wait > 250ms, this implies: > - it will not wait after sending the address-claimed message when the > claimed address has been spoofed, but the standard does not explicitly > states what to do in this case (see previous emails in this thread), so > it would be up to the application developer to decide how to manage the > conflict > - it will not wait after sending the address-claimed message when a > request for address-claimed message has been received as stated by the > standard Standard says: 1. No CF _shall_ begin, or resume, transmission on the network until 250 ms after it has successfully claimed an address (Figure 4). 2. This does not apply when responding to a request for address claimed. With current patch state: 1. is implemented and working as expected, 2. is not implemented. With this patch: 1. is partially broken and 2. is partially faking needed behavior. It will not wait if remote ECU which rebooted for some reasons. With this patch we are breaking one case of the standard in favor to fake compatibility to the other case. We should avoid waiting only based on presence of RfAC not based on the old_addr == new_addr. Without words 2. part should be implemented without breaking 1. > Otherwise you will have to keep track of above cases and decide if the > wait is needed or not, but this is hard do accomplish because is the > application in charge of sending the address-claimed message, so you > would have to decide how much to keep track of the request for address- > claimed message thus adding more complexity to the code of the driver. Current kernel already tracks all claims on the bus and knows all registered NAMEs. I do not see increased complicity in this case. IMHO, only missing part i a user space interface. Some thing like "ip n" will do. > Another solution is to let the driver send the address-claimed message > waiting or without waiting 250 ms for successive messages depending on > the case. You can send "address-claimed message" in any time you wont. Kernel will just not resolve the NAME to address until 1. part of the spec will apply. Do not forget, the NAME cache is used for local _and_ remote names. You can trick out local system, not remote. Even if you implement "smart" logic in user space and will know better then kernel, that this application is responding to RfAC. You will newer know if address-claimed message of remote system is a response to RfAC. From this perspective, I do not know, how allowing the user space break the rules will help to solve the problem? Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |