From: Eliav Farber <farbere@amazon.com>
To: <gregkh@linuxfoundation.org>, <kenneth.feng@amd.com>,
<alexander.deucher@amd.com>, <christian.koenig@amd.com>,
<airlied@gmail.com>, <simona@ffwll.ch>,
<linus.walleij@linaro.org>, <dmitry.torokhov@gmail.com>,
<tglx@linutronix.de>, <wens@csie.org>, <jernej.skrabec@gmail.com>,
<samuel@sholland.org>, <agk@redhat.com>, <snitzer@kernel.org>,
<mpatocka@redhat.com>, <clm@fb.com>, <dsterba@suse.com>,
<luc.vanoostenryck@gmail.com>, <pmladek@suse.com>,
<rostedt@goodmis.org>, <andriy.shevchenko@linux.intel.com>,
<linux@rasmusvillemoes.dk>, <senozhatsky@chromium.org>,
<akpm@linux-foundation.org>, <lijo.lazar@amd.com>,
<asad.kamal@amd.com>, <kevinyang.wang@amd.com>,
<David.Laight@ACULAB.COM>, <amd-gfx@lists.freedesktop.org>,
<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
<linux-input@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-sunxi@lists.linux.dev>, <dm-devel@lists.linux.dev>,
<linux-btrfs@vger.kernel.org>, <linux-sparse@vger.kernel.org>,
<stable@vger.kernel.org>, <farbere@amazon.com>
Cc: Arnd Bergmann <arnd@kernel.org>,
Christoph Hellwig <hch@infradead.org>,
Dan Carpenter <dan.carpenter@linaro.org>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Jens Axboe <axboe@kernel.dk>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Mateusz Guzik <mjguzik@gmail.com>,
"Matthew Wilcox" <willy@infradead.org>,
Pedro Falcato <pedro.falcato@gmail.com>
Subject: [PATCH v4 06/11 6.1.y] minmax.h: update some comments
Date: Fri, 3 Oct 2025 12:15:15 +0000 [thread overview]
Message-ID: <20251003121520.8176-7-farbere@amazon.com> (raw)
In-Reply-To: <20251003121520.8176-1-farbere@amazon.com>
From: David Laight <David.Laight@ACULAB.COM>
[ Upstream commit 10666e99204818ef45c702469488353b5bb09ec7 ]
- Change three to several.
- Remove the comment about retaining constant expressions, no longer true.
- Realign to nearer 80 columns and break on major punctiation.
- Add a leading comment to the block before __signed_type() and __is_nonneg()
Otherwise the block explaining the cast is a bit 'floating'.
Reword the rest of that comment to improve readability.
Link: https://lkml.kernel.org/r/85b050c81c1d4076aeb91a6cded45fee@AcuMS.aculab.com
Signed-off-by: David Laight <david.laight@aculab.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Mateusz Guzik <mjguzik@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Pedro Falcato <pedro.falcato@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Eliav Farber <farbere@amazon.com>
---
include/linux/minmax.h | 53 +++++++++++++++++++-----------------------
1 file changed, 24 insertions(+), 29 deletions(-)
diff --git a/include/linux/minmax.h b/include/linux/minmax.h
index 51b0d988e322..24e4b372649a 100644
--- a/include/linux/minmax.h
+++ b/include/linux/minmax.h
@@ -8,13 +8,10 @@
#include <linux/types.h>
/*
- * min()/max()/clamp() macros must accomplish three things:
+ * min()/max()/clamp() macros must accomplish several things:
*
* - Avoid multiple evaluations of the arguments (so side-effects like
* "x++" happen only once) when non-constant.
- * - Retain result as a constant expressions when called with only
- * constant expressions (to avoid tripping VLA warnings in stack
- * allocation usage).
* - Perform signed v unsigned type-checking (to generate compile
* errors instead of nasty runtime surprises).
* - Unsigned char/short are always promoted to signed int and can be
@@ -31,25 +28,23 @@
* bit #0 set if ok for unsigned comparisons
* bit #1 set if ok for signed comparisons
*
- * In particular, statically non-negative signed integer
- * expressions are ok for both.
+ * In particular, statically non-negative signed integer expressions
+ * are ok for both.
*
- * NOTE! Unsigned types smaller than 'int' are implicitly
- * converted to 'int' in expressions, and are accepted for
- * signed conversions for now. This is debatable.
+ * NOTE! Unsigned types smaller than 'int' are implicitly converted to 'int'
+ * in expressions, and are accepted for signed conversions for now.
+ * This is debatable.
*
- * Note that 'x' is the original expression, and 'ux' is
- * the unique variable that contains the value.
+ * Note that 'x' is the original expression, and 'ux' is the unique variable
+ * that contains the value.
*
- * We use 'ux' for pure type checking, and 'x' for when
- * we need to look at the value (but without evaluating
- * it for side effects! Careful to only ever evaluate it
- * with sizeof() or __builtin_constant_p() etc).
+ * We use 'ux' for pure type checking, and 'x' for when we need to look at the
+ * value (but without evaluating it for side effects!
+ * Careful to only ever evaluate it with sizeof() or __builtin_constant_p() etc).
*
- * Pointers end up being checked by the normal C type
- * rules at the actual comparison, and these expressions
- * only need to be careful to not cause warnings for
- * pointer use.
+ * Pointers end up being checked by the normal C type rules at the actual
+ * comparison, and these expressions only need to be careful to not cause
+ * warnings for pointer use.
*/
#define __signed_type_use(x, ux) (2 + __is_nonneg(x, ux))
#define __unsigned_type_use(x, ux) (1 + 2 * (sizeof(ux) < 4))
@@ -57,19 +52,19 @@
__signed_type_use(x, ux) : __unsigned_type_use(x, ux))
/*
- * To avoid warnings about casting pointers to integers
- * of different sizes, we need that special sign type.
+ * Check whether a signed value is always non-negative.
*
- * On 64-bit we can just always use 'long', since any
- * integer or pointer type can just be cast to that.
+ * A cast is needed to avoid any warnings from values that aren't signed
+ * integer types (in which case the result doesn't matter).
*
- * This does not work for 128-bit signed integers since
- * the cast would truncate them, but we do not use s128
- * types in the kernel (we do use 'u128', but they will
- * be handled by the !is_signed_type() case).
+ * On 64-bit any integer or pointer type can safely be cast to 'long'.
+ * But on 32-bit we need to avoid warnings about casting pointers to integers
+ * of different sizes without truncating 64-bit values so 'long' or 'long long'
+ * must be used depending on the size of the value.
*
- * NOTE! The cast is there only to avoid any warnings
- * from when values that aren't signed integer types.
+ * This does not work for 128-bit signed integers since the cast would truncate
+ * them, but we do not use s128 types in the kernel (we do use 'u128',
+ * but they are handled by the !is_signed_type() case).
*/
#ifdef CONFIG_64BIT
#define __signed_type(ux) long
--
2.47.3
next prev parent reply other threads:[~2025-10-03 13:01 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-03 12:15 [PATCH v4 00/11 6.1.y] Backport minmax.h updates from v6.17-rc7 Eliav Farber
2025-10-03 12:15 ` [PATCH v4 01/11 6.1.y] minmax: don't use max() in situations that want a C constant expression Eliav Farber
2025-10-06 10:39 ` Patch "minmax: don't use max() in situations that want a C constant expression" has been added to the 6.1-stable tree gregkh
2025-10-06 10:39 ` gregkh
2025-10-06 10:39 ` gregkh
2025-10-03 12:15 ` [PATCH v4 02/11 6.1.y] minmax: simplify min()/max()/clamp() implementation Eliav Farber
2025-10-06 10:39 ` Patch "minmax: simplify min()/max()/clamp() implementation" has been added to the 6.1-stable tree gregkh
2025-10-06 10:39 ` gregkh
2025-10-06 10:39 ` gregkh
2025-10-03 12:15 ` [PATCH v4 03/11 6.1.y] minmax: improve macro expansion and type checking Eliav Farber
2025-10-06 10:39 ` Patch "minmax: improve macro expansion and type checking" has been added to the 6.1-stable tree gregkh
2025-10-06 10:39 ` gregkh
2025-10-06 10:39 ` gregkh
2025-10-03 12:15 ` [PATCH v4 04/11 6.1.y] minmax: fix up min3() and max3() too Eliav Farber
2025-10-06 10:39 ` Patch "minmax: fix up min3() and max3() too" has been added to the 6.1-stable tree gregkh
2025-10-06 10:39 ` gregkh
2025-10-06 10:39 ` gregkh
2025-10-03 12:15 ` [PATCH v4 05/11 6.1.y] minmax.h: add whitespace around operators and after commas Eliav Farber
2025-10-06 10:39 ` Patch "minmax.h: add whitespace around operators and after commas" has been added to the 6.1-stable tree gregkh
2025-10-06 10:39 ` gregkh
2025-10-06 10:39 ` gregkh
2025-10-03 12:15 ` Eliav Farber [this message]
2025-10-06 10:39 ` Patch "minmax.h: update some comments" " gregkh
2025-10-06 10:39 ` gregkh
2025-10-06 10:39 ` gregkh
2025-10-03 12:15 ` [PATCH v4 07/11 6.1.y] minmax.h: reduce the #define expansion of min(), max() and clamp() Eliav Farber
2025-10-06 10:39 ` Patch "minmax.h: reduce the #define expansion of min(), max() and clamp()" has been added to the 6.1-stable tree gregkh
2025-10-06 10:39 ` gregkh
2025-10-06 10:39 ` gregkh
2025-10-03 12:15 ` [PATCH v4 08/11 6.1.y] minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp() Eliav Farber
2025-10-06 10:39 ` Patch "minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()" has been added to the 6.1-stable tree gregkh
2025-10-06 10:39 ` gregkh
2025-10-06 10:39 ` gregkh
2025-10-03 12:15 ` [PATCH v4 09/11 6.1.y] minmax.h: move all the clamp() definitions after the min/max() ones Eliav Farber
2025-10-06 10:39 ` Patch "minmax.h: move all the clamp() definitions after the min/max() ones" has been added to the 6.1-stable tree gregkh
2025-10-06 10:39 ` gregkh
2025-10-06 10:39 ` gregkh
2025-10-03 12:15 ` [PATCH v4 10/11 6.1.y] minmax.h: simplify the variants of clamp() Eliav Farber
2025-10-06 10:39 ` Patch "minmax.h: simplify the variants of clamp()" has been added to the 6.1-stable tree gregkh
2025-10-06 10:39 ` gregkh
2025-10-06 10:39 ` gregkh
2025-10-03 12:15 ` [PATCH v4 11/11 6.1.y] minmax.h: remove some #defines that are only expanded once Eliav Farber
2025-10-06 10:39 ` Patch "minmax.h: remove some #defines that are only expanded once" has been added to the 6.1-stable tree gregkh
2025-10-06 10:39 ` gregkh
2025-10-06 10:39 ` gregkh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251003121520.8176-7-farbere@amazon.com \
--to=farbere@amazon.com \
--cc=David.Laight@ACULAB.COM \
--cc=Jason@zx2c4.com \
--cc=agk@redhat.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=arnd@kernel.org \
--cc=asad.kamal@amd.com \
--cc=axboe@kernel.dk \
--cc=christian.koenig@amd.com \
--cc=clm@fb.com \
--cc=dan.carpenter@linaro.org \
--cc=dm-devel@lists.linux.dev \
--cc=dmitry.torokhov@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=dsterba@suse.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=jernej.skrabec@gmail.com \
--cc=kenneth.feng@amd.com \
--cc=kevinyang.wang@amd.com \
--cc=lijo.lazar@amd.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=linux@rasmusvillemoes.dk \
--cc=lorenzo.stoakes@oracle.com \
--cc=luc.vanoostenryck@gmail.com \
--cc=mjguzik@gmail.com \
--cc=mpatocka@redhat.com \
--cc=pedro.falcato@gmail.com \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=samuel@sholland.org \
--cc=senozhatsky@chromium.org \
--cc=simona@ffwll.ch \
--cc=snitzer@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=wens@csie.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.