linux-kernel - Re: [PATCH] can: flexcan: simplify the calculation of priv->mb

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] [day] [month] [year] [list]

Message-ID: <20241104-graceful-slug-of-growth-0ee47f-mkl@pengutronix.de>
Date: Mon, 4 Nov 2024 11:39:04 +0100
From: Marc Kleine-Budde <mkl@...gutronix.de>
To: Vincent Mailhol <mailhol.vincent@...adoo.fr>
Cc: "baozhu.liu" <lucas.liu@...ngine.com>, wg@...ndegger.com, 
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, linux-can@...r.kernel.org, 
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] can: flexcan: simplify the calculation of priv->mb_count

On 04.11.2024 19:31:30, Vincent Mailhol wrote:
> On Mon. 4 Nov. 2024 at 18:05, baozhu.liu <lucas.liu@...ngine.com> wrote:
> > Since mb is a fixed-size two-dimensional array (u8 mb[2][512]),
> > "priv->mb_count = sizeof(priv->regs->mb)/priv->mb_size;",
> > this expression calculates mb_count correctly and is more concise.
> 
> When using integers,
> 
>   (a1 / q) + (a2 / q)
> 
> is not necessarily equal to
> 
>   (a1 + a2) / q.
> 
> 
> If the decimal place of
> 
>   sizeof(priv->regs->mb[0]) / priv->mb_size
> 
> were to be greater than or equal to 0.5, the result would have changed
> because of the rounding.
> 
> This is illustrated in https://godbolt.org/z/bfnhKcKPo.
> 
> Here, luckily enough, the two valid results are, for CAN CC:
> 
>   sizeof(priv->regs->mb[0]) / priv->mb_size = 512 / 16
>                                             = 64
> 
> and for CAN FD:
> 
>   sizeof(priv->regs->mb[0]) / priv->mb_size = 512 / 72
>                                             = 14.22
> 
> and both of these have no rounding issues.
> 
> I am not sure if we should take this patch. It is correct at the end
> because you "won a coin flip", but the current code is doing the
> correct logical calculation which would always yield the correct
> result regardless of the rounding.

Wow, that's an elaborative answer. Thanks Vincent!

And yes the current code does the correct logical calculation because of
the underlying restrictions of the hardware. A CAN-CC/FD frame cannot
cross the boundary between the 2 memory areas.

If you want to improve something, feel free to add a comment explaining
the reasoning for the existing calculation.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)