korg/linux
0
0
Fork 0
mirror of https://mirrors.bfsu.edu.cn/git/linux.git synced 2024-11-11 12:28:41 +08:00
Code Issues Packages Projects Releases Wiki Activity

linux-can-fixes-for-6.2-20230207

Browse Source 
-----BEGIN PGP SIGNATURE-----
 
 iQFHBAABCgAxFiEEDs2BvajyNKlf9TJQvlAcSiqKBOgFAmPiWbYTHG1rbEBwZW5n
 dXRyb25peC5kZQAKCRC+UBxKKooE6HT3CACcKiUxmkFfS3I2MUCLt+spz2/4q3cG
 +MX8m03fzSU8efdKN1ckUOmQfsPp2RNP7NSeI/Anu83oka40zFuejC/Dfg9V1SBF
 EKD39VIWQTuPcYJP4GlxqKTkDHSVsA5iN/4vxzCFpp7C6LR3h2f0bTwj6SA44IvD
 eatH6Vzr/Y1rG6Yj27hZzFpC8HXqHzaIcC1UJpODqNTmhrux/hskem0XqH68VQXK
 FRi8K7xHgIs4MonamWGJj/oz1NkbEje3xvT4nZRkaMLgZY0prTQfJetSDaGwkBci
 WJmqJ15PpBRedDpdTIeXkZK8U95BWt/gZEp28XwgkohP6A8DsilJFS7F
 =Tcyi
 -----END PGP SIGNATURE-----

Merge tag 'linux-can-fixes-for-6.2-20230207' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can

Marc Kleine-Budde says:

====================
can 2023-02-07

The patch is from Devid Antonio Filoni and fixes an address claiming
problem in the J1939 CAN protocol.

* tag 'linux-can-fixes-for-6.2-20230207' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can:
  can: j1939: do not wait 250 ms if the same addr was already claimed
====================

Link: https://lore.kernel.org/r/20230207140514.2885065-1-mkl@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This commit is contained in:
Jakub Kicinski 2023-02-07 20:50:30 -08:00
commit b1f4fbabbb
1 changed files with 40 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
net/can/j1939/address-claim.c
View File

@ -165,6 +165,46 @@ static void j1939_ac_process(struct j1939_priv *priv, struct sk_buff *skb)
* leaving this function.
*/
ecu = j1939_ecu_get_by_name_locked(priv, name);
if (ecu && ecu->addr == skcb->addr.sa) {
/* The ISO 11783-5 standard, in "4.5.2 - Address claim
* requirements", states:
* d) No CF shall begin, or resume, transmission on the
* network until 250 ms after it has successfully claimed
* an address except when responding to a request for
* address-claimed.
*
* But "Figure 6" and "Figure 7" in "4.5.4.2 - Address-claim
* prioritization" show that the CF begins the transmission
* after 250 ms from the first AC (address-claimed) message
* even if it sends another AC message during that time window
* to resolve the address contention with another CF.
*
* As stated in "4.4.2.3 - Address-claimed message":
* In order to successfully claim an address, the CF sending
* an address claimed message shall not receive a contending
* claim from another CF for at least 250 ms.
*
* As stated in "4.4.3.2 - NAME management (NM) message":
* 1) A commanding CF can
* d) request that a CF with a specified NAME transmit
* the address-claimed message with its current NAME.
* 2) A target CF shall
* d) send an address-claimed message in response to a
* request for a matching NAME
*
* Taking the above arguments into account, the 250 ms wait is
* requested only during network initialization.
*
* Do not restart the timer on AC message if both the NAME and
* the address match and so if the address has already been
* claimed (timer has expired) or the AC message has been sent
* to resolve the contention with another CF (timer is still
* running).
*/
goto out_ecu_put;
}
if (!ecu && j1939_address_is_unicast(skcb->addr.sa))
ecu = j1939_ecu_create_locked(priv, name);