linux-kernel - Re: [PATCH RESEND] can: j1939: do not wait 250ms if the same addr was already claimed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YnllpntZ8V5CD07v@x1.vandijck-laurijssen.be>
Date:   Mon, 9 May 2022 21:04:06 +0200
From:   Kurt Van Dijck <dev.kurt@...dijck-laurijssen.be>
To:     Devid Antonio Filoni <devid.filoni@...uetechnologies.com>
Cc:     Robin van der Gracht <robin@...tonic.nl>,
        Oleksij Rempel <o.rempel@...gutronix.de>,
        kernel@...gutronix.de, linux-can@...r.kernel.org,
        Oleksij Rempel <linux@...pel-privat.de>,
        Oliver Hartkopp <socketcan@...tkopp.net>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Maxime Jayat <maxime.jayat@...ile-devices.fr>,
        kbuild test robot <lkp@...el.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND] can: j1939: do not wait 250ms if the same addr
 was already claimed

On ma, 09 mei 2022 19:03:03 +0200, Devid Antonio Filoni wrote:
> This is not explicitly stated in SAE J1939-21 and some tools used for
> ISO-11783 certification do not expect this wait.

IMHO, the current behaviour is not explicitely stated, but nor is the opposite.
And if I'm not mistaken, this introduces a 250msec delay.

1. If you want to avoid the 250msec gap, you should avoid to contest the same address.

2. It's a balance between predictability and flexibility, but if you try to accomplish both,
as your patch suggests, there is slight time-window until the current owner responds,
in which it may be confusing which node has the address. It depends on how much history
you have collected on the bus.

I'm sure that this problem decreases with increasing processing power on the nodes,
but bigger internal queues also increase this window.

It would certainly help if you describe how the current implementation fails.

Would decreasing the dead time to 50msec help in such case.

Kind regards,
Kurt