[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9258be5d31104805b63bb1a64317a448@AcuMS.aculab.com>
Date: Tue, 20 Jun 2023 12:06:49 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Andy Shevchenko' <andriy.shevchenko@...ux.intel.com>,
Jens Axboe <axboe@...nel.dk>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v1 1/1] pktcdvd: Use clamp_val() instead of min()+max()
From: Andy Shevchenko
> Sent: 16 June 2023 15:26
>
> In a couple of places replace min()+max() pair by clamp_val().
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> ---
> drivers/block/pktcdvd.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> index a1428538bda5..18a960bb6165 100644
> --- a/drivers/block/pktcdvd.c
> +++ b/drivers/block/pktcdvd.c
> @@ -208,14 +208,11 @@ static DEVICE_ATTR_RO(size);
> static void init_write_congestion_marks(int* lo, int* hi)
> {
> if (*hi > 0) {
> - *hi = max(*hi, 500);
> - *hi = min(*hi, 1000000);
> + *hi = clamp_val(*hi, 500, 1000000);
(standard rant about minmax.h)
clamp_val() is pretty much broken by design.
It MIGHT be ok here but it casts both limits to the
type of the value being compared.
In general that is just plain wrong.
Like min_t() it is generally ok because the kernel only uses
unsigned values between 0 and MAXINT.
If min/max were ok, then using clamp() should also be ok.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists