linux-kernel - RE: [PATCH net-next] net: mvpp2: Improve data types and use min()

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: <3f8d78d6b539465c8040888409eb35a7@AcuMS.aculab.com>
Date: Wed, 17 Jul 2024 12:30:35 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Thorsten Blum' <thorsten.blum@...lux.com>, "Russell King (Oracle)"
	<linux@...linux.org.uk>
CC: "marcin.s.wojtas@...il.com" <marcin.s.wojtas@...il.com>,
	"davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
	<edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net-next] net: mvpp2: Improve data types and use min()

From: Thorsten Blum
> Sent: 16 July 2024 18:49
> 
> On 15. Jul 2024, at 17:44, Russell King (Oracle) <linux@...linux.org.uk> wrote:
> > On Thu, Jul 11, 2024 at 05:47:43PM +0200, Thorsten Blum wrote:
> >> Change the data type of the variable freq in mvpp2_rx_time_coal_set()
> >> and mvpp2_tx_time_coal_set() to u32 because port->priv->tclk also has
> >> the data type u32.
> >>
> >> Change the data type of the function parameter clk_hz in
> >> mvpp2_usec_to_cycles() and mvpp2_cycles_to_usec() to u32 accordingly
> >> and remove the following Coccinelle/coccicheck warning reported by
> >> do_div.cocci:
> >>
> >>  WARNING: do_div() does a 64-by-32 division, please consider using div64_ul instead
> >>
> >> Use min() to simplify the code and improve its readability.
> >>
> >> Compile-tested only.
> >>
> >> Signed-off-by: Thorsten Blum <thorsten.blum@...lux.com>
> >
> > I'm still on holiday, but it's a wet day today. Don't expect replies
> > from me to be regular.
> >
> > I don't think this is a good idea.
> >
> > priv->tclk comes from clk_get_rate() which returns an unsigned long.
> > tclk should _also_ be an unsigned long, not a u32, so that the range
> > of values clk_get_rate() returns can be represented without being
> > truncted.
> >
> > Thus the use of unsigned long elsewhere where tclk is passed into is
> > actually correct.
> 
> I don't think tclk should be an unsigned long.
> 
> In [1] Eric Dumazet wrote:
> 
>   "This is silly, clk_hz fits in a u32, why pretends it is 64bit ?"
> 
> and all functions in mvpp2_main.c (mvpp2_write(), do_div(),
> device_property_read_u32(), and mvpp22_gop_fca_set_timer()), which have
> tclk as a direct or indirect argument, assume tclk is a u32.
> 
> Although mvpp2_cycles_to_usec() suggests it can be called with an
> unsigned long clk_hz, do_div() then immediately casts it to a u32
> anyway.
> 
> Yes, the function clk_get_rate() returns an unsigned long according to
> its signature, but tclk is always used as a u32 afterwards.
> 
> I'm not familiar with the hardware, but I guess the clock rate always
> fits into 32 bits (just like Eric wrote)?

'long' can't be correct - it is 32bit on 32bit systems.
They are just as likely to have a clock that is faster than 4GHz than a 64bit system.

The type should either be u64 or u32 (or just unsigned int - Linux isn't going to
get far if int is 16 bits).
This is true of a lot of the uses of 'long'.

There are cases where 'long' will generate better code than 'int' on 64bit systems.
In particular it can save sign/zero extension (and maybe masking) of function
parameters and results.
But that is only likely to matter on very hot paths - and particularly for array indexes.
(OTOH the masking for char/short is likely to be really horrid on anything except x86.)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)