linux-kernel - Re: [virtio-dev] [RFC PATCH 1/1] can: virtio: Initial virtio CAN driver.

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: <9bdba1e2-9d1f-72b3-8793-24851c11e953@opensynergy.com>
Date:   Fri, 12 May 2023 15:19:24 +0200
From:   Harald Mommer <harald.mommer@...nsynergy.com>
To:     Vincent Mailhol <vincent.mailhol@...il.com>,
        Arnd Bergmann <arnd@...nel.org>,
        Mikhail Golubev <Mikhail.Golubev@...nsynergy.com>
Cc:     Harald Mommer <hmo@...nsynergy.com>,
        virtio-dev@...ts.oasis-open.org, linux-can@...r.kernel.org,
        Netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org,
        Wolfgang Grandegger <wg@...ndegger.com>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Dariusz Stojaczyk <Dariusz.Stojaczyk@...nsynergy.com>,
        Stratos Mailing List <stratos-dev@...lists.linaro.org>
Subject: Re: [virtio-dev] [RFC PATCH 1/1] can: virtio: Initial virtio CAN
 driver.

Hello Vincent,

searched for the old E-Mail, this was one of that which slipped through. 
Too much of those.

On 05.11.22 10:21, Vincent Mailhol wrote:
> On Fry. 4 nov. 2022 at 20:13, Arnd Bergmann <arnd@...nel.org> wrote:
>> On Thu, Nov 3, 2022, at 13:26, Harald Mommer wrote:
>>> On 25.08.22 20:21, Arnd Bergmann wrote:
>> ...
>>> The messages are not necessarily processed in sequence by the CAN stack.
>>> CAN is priority based. The lower the CAN ID the higher the priority. So
>>> a message with CAN ID 0x100 can surpass a message with ID 0x123 if the
>>> hardware is not just simple basic CAN controller using a single TX
>>> mailbox with a FIFO queue on top of it.
> Really? I acknowledge that it is priority based *on the bus*, i.e. if
> two devices A and B on the same bus try to send CAN ID 0x100 and 0x123
> at the same time, then device A will win the CAN arbitration.
> However, I am not aware of any devices which reorder their own stack
> according to the CAN IDs. If I first send CAN ID 0x123 and then ID
> 0x100 on the device stack, 0x123 would still go out first, right?

The CAN hardware may be a basic CAN hardware: Single mailbox only with a 
TX FIFO on top of this.

No reordering takes place, the CAN hardware will try to arbitrate the 
CAN bus with a low priority CAN message (big CAN ID) while some high 
priority CAN message (small CAN ID) is waiting in the FIFO. This is 
called "internal priority inversion", a property of basic CAN hardware. 
A basic CAN hardware does exactly what you describe.

Should be the FIFO in software it's a bad idea to try to improve this 
doing some software sorting, the processing time needed is likely to 
make things even worse. Therefore no software does this or at least it's 
not recommended to do this.

But the hardware may also be a better one. No FIFO but a lot of TX 
mailboxes. A full CAN hardware tries to arbitrate the bus using the 
highest priority waiting CAN message considering all hardware TX 
mailboxes. Such a better (full CAN) hardware does not cause "internal 
priority inversion" but tries to arbitrate the bus in the correct order 
given by the message IDs.

We don't know about the actually used CAN hardware and how it's used on 
this level we are with our virtio can device. We are using SocketCAN, no 
information about the properties of the underlying hardware is provided 
at some API. May be basic CAN using a FIFO and a single TX mailbox or 
full CAN using a lot of TX mailboxes in parallel.

On the bus it's guaranteed always that the sender with the lowest CAN ID 
winds regardless which hardware is used, the only difference is whether 
we have "internal priority inversion" or not.

If I look at the CAN stack = Software + hardware (and not only software) 
it's correct: The hardware device may re-order if it's a better (full 
CAN) one and thus the actual sending on the bus is not done in the same 
sequence as the messages were provided internally (e.g. at some socket).

Regards
Harald