[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <395aa6d3-c423-266e-28e1-43f8d66dce2a@intel.com>
Date: Mon, 28 Nov 2022 10:31:04 -0800
From: Jacob Keller <jacob.e.keller@...el.com>
To: David Laight <David.Laight@...LAB.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
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, ...)?
>
> ...
>> + 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?
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
>
Powered by blists - more mailing lists