[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7a0e89ad75334d90ba5b9c0623ed573b@AcuMS.aculab.com>
Date: Tue, 22 Nov 2022 09:07:59 +0000
From: David Laight <David.Laight@...LAB.COM>
To: "'Elliott, Robert (Servers)'" <elliott@....com>,
"Jason A. Donenfeld" <Jason@...c4.com>
CC: "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
"davem@...emloft.net" <davem@...emloft.net>,
"tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
"ap420073@...il.com" <ap420073@...il.com>,
"ardb@...nel.org" <ardb@...nel.org>,
"ebiggers@...nel.org" <ebiggers@...nel.org>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v4 10/24] crypto: x86/poly - limit FPU preemption
From: Elliott, Robert
> Sent: 22 November 2022 05:06
...
> Since enum doesn't guarantee any particular type, those variations
> upset the min() macro. min_t() is necessary to eliminate the
> compiler warning.
Yes, min() is fundamentally broken. min_t() isn't really a solution.
I think min() needs to include something like:
#define min(a, b) \
__builtin_constant(b) && (b) + 0u <= MAX_INT ? \
((a) < (int)(b) ? (a) : (int)(b)) : \
...
So in the common case where 'b' is a small constant integer it
doesn't matter whether the is it signed or unsigned.
I might try compiling a kernel where min_t() does that instead
of the casts - just to see how many of the casts are actually
needed.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists