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]
Date:   Tue, 29 Nov 2022 08:54:25 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Jacob Keller' <jacob.e.keller@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     Jiri Pirko <jiri@...dia.com>, Jakub Kicinski <kuba@...nel.org>
Subject: RE: [PATCH net-next v2 1/9] devlink: use min_t to calculate data_size

From: Jacob Keller
> Sent: 28 November 2022 18:31
> 
> On 11/24/2022 1:53 PM, David Laight wrote:
> > From: Jacob Keller
> >> Sent: 23 November 2022 20:38
> >>
> >> The calculation for the data_size in the devlink_nl_read_snapshot_fill
> >> function uses an if statement that is better expressed using the min_t
> >> macro.
> >
> > There ought to be a 'duck shoot' arranged for all uses of min_t().
> > I was testing a patch (I might submit next week) that relaxes the
> > checks in min() so that it doesn't error a lot of valid cases.
> > In particular a positive integer constant can always be cast to (int)
> > and the compare will DTRT.
> >
> > I found things like min_t(u32, u32_length, u64_limit) where
> > you really don't want to mask the limit down.
> > There are also the min_t(u8, ...) and min_t(u16, ...).
> >
> 
> Wouldn't that example just want to be min_t(u64, ...)?

That is what is would need to be.
But the compiler can work it out and get it right.

> > ...
> >> +		data_size = min_t(u32, end_offset - curr_offset,
> >> +				  DEVLINK_REGION_READ_CHUNK_SIZE);
> >
> > Here I think both xxx_offset are u32 - so the CHUNK_SIZE
> > constant probably needs a U suffix.
> 
> Right. My understanding was that min_t would cast everything to a u32
> when doing such comparison, and we know that
> DEVLINK_REGION_READ_CHUNK_SIZE is < U32_MAX so this is ok?
> 
> Or am I misunderstanding?

The code isn't wrong, except that errors from min() are really
an indication that the types mismatch, not that you should add
loads of casts.
You wouldn't think:
	x = (int)a + (int)b;
was anything normal, but that is what min_t() does.

	David

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ