linux-kernel - Re: [PATCH v5] 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: <2332595.vFx2qVVIhK@fedora.fritz.box>
Date: Tue, 14 Oct 2025 08:54:23 +0200
From: Francesco Valla <francesco@...la.it>
To: Matias Ezequiel Vara Larsen <mvaralar@...hat.com>
Cc: Marc Kleine-Budde <mkl@...gutronix.de>, Paolo Abeni <pabeni@...hat.com>,
 Harald Mommer <harald.mommer@...nsynergy.com>,
 Mikhail Golubev-Ciuchea <Mikhail.Golubev-Ciuchea@...nsynergy.com>,
 Wolfgang Grandegger <wg@...ndegger.com>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, "Michael S. Tsirkin" <mst@...hat.com>,
 Jason Wang <jasowang@...hat.com>, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
 Damir Shaikhutdinov <Damir.Shaikhutdinov@...nsynergy.com>,
 linux-kernel@...r.kernel.org, linux-can@...r.kernel.org,
 netdev@...r.kernel.org, virtualization@...ts.linux.dev,
 development@...aril.me
Subject: Re: [PATCH v5] can: virtio: Initial virtio CAN driver.

On Monday, 13 October 2025 at 18:35:51 Matias Ezequiel Vara Larsen <mvaralar@...hat.com> wrote:
> On Thu, Sep 11, 2025 at 10:59:40PM +0200, Francesco Valla wrote:
> > [...]
> > 
> > > +
> > > +/* TX queue message types */
> > > +struct virtio_can_tx_out {
> > > +#define VIRTIO_CAN_TX                   0x0001
> > > +	__le16 msg_type;
> > > +	__le16 length; /* 0..8 CC, 0..64 CAN-FD, 0..2048 CAN-XL, 12 bits */
> > > +	__u8 reserved_classic_dlc; /* If CAN classic length = 8 then DLC can be 8..15 */
> > > +	__u8 padding;
> > > +	__le16 reserved_xl_priority; /* May be needed for CAN XL priority */
> > > +	__le32 flags;
> > > +	__le32 can_id;
> > > +	__u8 sdu[64];
> > > +};
> > > +
> > 
> > sdu[] here might be a flexible array, if the driver allocates
> > virtio_can_tx_out structs dyncamically (see above). This would be
> > beneficial in case of CAN-XL frames (if/when they will be supported).
> > 
> 
> If we use a flexible array for sdu[] here, then we will have a problem
> when defining the virtio_can_tx struct since it is not in the end of the
> structure. I think it is a good idea to define it as a flexible array
> but I do not know how. 

In this case, I'd move struct virtio_can_tx_out at the end of the
virtio_can_tx struct - in this way, sdu[] would be at the end:

struct virtio_can_tx {
	struct list_head list;
	unsigned int putidx;
	struct virtio_can_tx_in tx_in;
	struct virtio_can_tx_out tx_out;
};

Maybe an additional comment declaring why it is done this way would
be a good idea? Also considering that the two structures are defined
in different files.

Francesco