From: Eliav Farber <farbere@amazon.com>
To: <richard@nod.at>, <anton.ivanov@cambridgegreys.com>,
<johannes@sipsolutions.net>, <dave.hansen@linux.intel.com>,
<luto@kernel.org>, <peterz@infradead.org>, <tglx@linutronix.de>,
<mingo@redhat.com>, <bp@alien8.de>, <x86@kernel.org>,
<hpa@zytor.com>, <tony.luck@intel.com>, <qiuxu.zhuo@intel.com>,
<james.morse@arm.com>, <mchehab@kernel.org>, <rric@kernel.org>,
<harry.wentland@amd.com>, <sunpeng.li@amd.com>,
<Rodrigo.Siqueira@amd.com>, <alexander.deucher@amd.com>,
<christian.koenig@amd.com>, <Xinhui.Pan@amd.com>,
<airlied@gmail.com>, <daniel@ffwll.ch>, <evan.quan@amd.com>,
<maarten.lankhorst@linux.intel.com>, <mripard@kernel.org>,
<tzimmermann@suse.de>, <jdelvare@suse.com>, <linux@roeck-us.net>,
<linus.walleij@linaro.org>, <dmitry.torokhov@gmail.com>,
<wens@csie.org>, <jernej.skrabec@gmail.com>,
<samuel@sholland.org>, <agk@redhat.com>, <snitzer@kernel.org>,
<dm-devel@lists.linux.dev>, <mailhol.vincent@wanadoo.fr>,
<wg@grandegger.com>, <mkl@pengutronix.de>, <davem@davemloft.net>,
<edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
<alexandre.torgue@foss.st.com>, <joabreu@synopsys.com>,
<mcoquelin.stm32@gmail.com>, <krzysztof.kozlowski@linaro.org>,
<malattia@linux.it>, <hdegoede@redhat.com>,
<ilpo.jarvinen@linux.intel.com>, <markgross@kernel.org>,
<artur.paszkiewicz@intel.com>, <jejb@linux.ibm.com>,
<martin.petersen@oracle.com>, <sakari.ailus@linux.intel.com>,
<gregkh@linuxfoundation.org>, <clm@fb.com>,
<josef@toxicpanda.com>, <dsterba@suse.com>,
<luc.vanoostenryck@gmail.com>, <rostedt@goodmis.org>,
<mhiramat@kernel.org>, <pmladek@suse.com>,
<andriy.shevchenko@linux.intel.com>, <linux@rasmusvillemoes.dk>,
<senozhatsky@chromium.org>, <minchan@kernel.org>,
<akpm@linux-foundation.org>, <dsahern@kernel.org>,
<shuah@kernel.org>, <keescook@chromium.org>, <wad@chromium.org>,
<farbere@amazon.com>, <David.Laight@ACULAB.COM>,
<arnd@kernel.org>, <linux-um@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <linux-edac@vger.kernel.org>,
<amd-gfx@lists.freedesktop.org>,
<dri-devel@lists.freedesktop.org>, <linux-hwmon@vger.kernel.org>,
<linux-input@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-sunxi@lists.linux.dev>, <linux-media@vger.kernel.org>,
<linux-can@vger.kernel.org>, <netdev@vger.kernel.org>,
<linux-stm32@st-md-mailman.stormreply.com>,
<platform-driver-x86@vger.kernel.org>,
<linux-scsi@vger.kernel.org>, <linux-staging@lists.linux.dev>,
<linux-btrfs@vger.kernel.org>, <linux-sparse@vger.kernel.org>,
<linux-trace-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
<linux-kselftest@vger.kernel.org>, <bpf@vger.kernel.org>,
<stable@vger.kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
David Laight <David.Laight@aculab.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Subject: [PATCH 03/15 6.6.y] minmax: add a few more MIN_T/MAX_T users
Date: Mon, 22 Sep 2025 10:32:29 +0000 [thread overview]
Message-ID: <20250922103241.16213-4-farbere@amazon.com> (raw)
In-Reply-To: <20250922103241.16213-1-farbere@amazon.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
[ Upstream commit 4477b39c32fdc03363affef4b11d48391e6dc9ff ]
Commit 3a7e02c040b1 ("minmax: avoid overly complicated constant
expressions in VM code") added the simpler MIN_T/MAX_T macros in order
to avoid some excessive expansion from the rather complicated regular
min/max macros.
The complexity of those macros stems from two issues:
(a) trying to use them in situations that require a C constant
expression (in static initializers and for array sizes)
(b) the type sanity checking
and MIN_T/MAX_T avoids both of these issues.
Now, in the whole (long) discussion about all this, it was pointed out
that the whole type sanity checking is entirely unnecessary for
min_t/max_t which get a fixed type that the comparison is done in.
But that still leaves min_t/max_t unnecessarily complicated due to
worries about the C constant expression case.
However, it turns out that there really aren't very many cases that use
min_t/max_t for this, and we can just force-convert those.
This does exactly that.
Which in turn will then allow for much simpler implementations of
min_t()/max_t(). All the usual "macros in all upper case will evaluate
the arguments multiple times" rules apply.
We should do all the same things for the regular min/max() vs MIN/MAX()
cases, but that has the added complexity of various drivers defining
their own local versions of MIN/MAX, so that needs another level of
fixes first.
Link: https://lore.kernel.org/all/b47fad1d0cf8449886ad148f8c013dae@AcuMS.aculab.com/
Cc: David Laight <David.Laight@aculab.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Eliav Farber <farbere@amazon.com>
---
arch/x86/mm/pgtable.c | 2 +-
drivers/edac/sb_edac.c | 4 ++--
drivers/gpu/drm/drm_color_mgmt.c | 2 +-
drivers/md/dm-integrity.c | 6 +++---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
net/ipv4/proc.c | 2 +-
net/ipv6/proc.c | 2 +-
7 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index b18f5a71e679..98aa303ad054 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -107,7 +107,7 @@ static inline void pgd_list_del(pgd_t *pgd)
#define UNSHARED_PTRS_PER_PGD \
(SHARED_KERNEL_PMD ? KERNEL_PGD_BOUNDARY : PTRS_PER_PGD)
#define MAX_UNSHARED_PTRS_PER_PGD \
- max_t(size_t, KERNEL_PGD_BOUNDARY, PTRS_PER_PGD)
+ MAX_T(size_t, KERNEL_PGD_BOUNDARY, PTRS_PER_PGD)
static void pgd_set_mm(pgd_t *pgd, struct mm_struct *mm)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index 0c779a0326b6..6c3a40e6f4c6 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -109,8 +109,8 @@ static const u32 knl_interleave_list[] = {
0x104, 0x10c, 0x114, 0x11c, /* 20-23 */
};
#define MAX_INTERLEAVE \
- (max_t(unsigned int, ARRAY_SIZE(sbridge_interleave_list), \
- max_t(unsigned int, ARRAY_SIZE(ibridge_interleave_list), \
+ (MAX_T(unsigned int, ARRAY_SIZE(sbridge_interleave_list), \
+ MAX_T(unsigned int, ARRAY_SIZE(ibridge_interleave_list), \
ARRAY_SIZE(knl_interleave_list))))
struct interleave_pkg {
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index d021497841b8..3969dc548cff 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -532,7 +532,7 @@ int drm_plane_create_color_properties(struct drm_plane *plane,
{
struct drm_device *dev = plane->dev;
struct drm_property *prop;
- struct drm_prop_enum_list enum_list[max_t(int, DRM_COLOR_ENCODING_MAX,
+ struct drm_prop_enum_list enum_list[MAX_T(int, DRM_COLOR_ENCODING_MAX,
DRM_COLOR_RANGE_MAX)];
int i, len;
diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c
index 1e27a5bce2d9..0bd76f8d4dc6 100644
--- a/drivers/md/dm-integrity.c
+++ b/drivers/md/dm-integrity.c
@@ -1794,7 +1794,7 @@ static void integrity_metadata(struct work_struct *w)
struct bio *bio = dm_bio_from_per_bio_data(dio, sizeof(struct dm_integrity_io));
char *checksums;
unsigned int extra_space = unlikely(digest_size > ic->tag_size) ? digest_size - ic->tag_size : 0;
- char checksums_onstack[max_t(size_t, HASH_MAX_DIGESTSIZE, MAX_TAG_SIZE)];
+ char checksums_onstack[MAX_T(size_t, HASH_MAX_DIGESTSIZE, MAX_TAG_SIZE)];
sector_t sector;
unsigned int sectors_to_process;
@@ -2073,7 +2073,7 @@ static bool __journal_read_write(struct dm_integrity_io *dio, struct bio *bio,
} while (++s < ic->sectors_per_block);
#ifdef INTERNAL_VERIFY
if (ic->internal_hash) {
- char checksums_onstack[max_t(size_t, HASH_MAX_DIGESTSIZE, MAX_TAG_SIZE)];
+ char checksums_onstack[MAX_T(size_t, HASH_MAX_DIGESTSIZE, MAX_TAG_SIZE)];
integrity_sector_checksum(ic, logical_sector, mem + bv.bv_offset, checksums_onstack);
if (unlikely(memcmp(checksums_onstack, journal_entry_tag(ic, je), ic->tag_size))) {
@@ -2638,7 +2638,7 @@ static void do_journal_write(struct dm_integrity_c *ic, unsigned int write_start
unlikely(from_replay) &&
#endif
ic->internal_hash) {
- char test_tag[max_t(size_t, HASH_MAX_DIGESTSIZE, MAX_TAG_SIZE)];
+ char test_tag[MAX_T(size_t, HASH_MAX_DIGESTSIZE, MAX_TAG_SIZE)];
integrity_sector_checksum(ic, sec + ((l - j) << ic->sb->log2_sectors_per_block),
(char *)access_journal_data(ic, i, l), test_tag);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index ff5389a8efc3..f3155d69a013 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2841,7 +2841,7 @@ static void stmmac_dma_interrupt(struct stmmac_priv *priv)
u32 channels_to_check = tx_channel_count > rx_channel_count ?
tx_channel_count : rx_channel_count;
u32 chan;
- int status[max_t(u32, MTL_MAX_TX_QUEUES, MTL_MAX_RX_QUEUES)];
+ int status[MAX_T(u32, MTL_MAX_TX_QUEUES, MTL_MAX_RX_QUEUES)];
/* Make sure we never check beyond our status buffer. */
if (WARN_ON_ONCE(channels_to_check > ARRAY_SIZE(status)))
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index a85b0aba3646..b444767b15a5 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -43,7 +43,7 @@
#include <net/sock.h>
#include <net/raw.h>
-#define TCPUDP_MIB_MAX max_t(u32, UDP_MIB_MAX, TCP_MIB_MAX)
+#define TCPUDP_MIB_MAX MAX_T(u32, UDP_MIB_MAX, TCP_MIB_MAX)
/*
* Report socket allocation statistics [mea@utu.fi]
diff --git a/net/ipv6/proc.c b/net/ipv6/proc.c
index 6d1d9221649d..752327b10dde 100644
--- a/net/ipv6/proc.c
+++ b/net/ipv6/proc.c
@@ -27,7 +27,7 @@
#include <net/ipv6.h>
#define MAX4(a, b, c, d) \
- max_t(u32, max_t(u32, a, b), max_t(u32, c, d))
+ MAX_T(u32, MAX_T(u32, a, b), MAX_T(u32, c, d))
#define SNMP_MIB_MAX MAX4(UDP_MIB_MAX, TCP_MIB_MAX, \
IPSTATS_MIB_MAX, ICMP_MIB_MAX)
--
2.47.3
next prev parent reply other threads:[~2025-09-22 10:34 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-22 10:32 [PATCH 00/15 v6.6.y] Backport minmax.h updates from v6.17-rc7 Eliav Farber
2025-09-22 10:32 ` [PATCH 01/15 6.6.y] minmax: avoid overly complicated constant expressions in VM code Eliav Farber
2025-09-22 12:26 ` Patch "minmax: avoid overly complicated constant expressions in VM code" has been added to the 6.6-stable tree gregkh
2025-09-22 12:26 ` gregkh
2025-09-22 12:26 ` gregkh
2025-09-22 10:32 ` [PATCH 02/15 6.6.y] minmax: simplify and clarify min_t()/max_t() implementation Eliav Farber
2025-09-22 12:27 ` Patch "minmax: simplify and clarify min_t()/max_t() implementation" has been added to the 6.6-stable tree gregkh
2025-09-22 12:27 ` gregkh
2025-09-22 12:27 ` gregkh
2025-09-22 10:32 ` Eliav Farber [this message]
2025-09-22 12:26 ` Patch "minmax: add a few more MIN_T/MAX_T users" " gregkh
2025-09-22 12:26 ` gregkh
2025-09-22 12:26 ` gregkh
2025-09-22 12:26 ` gregkh
2025-09-22 10:32 ` [PATCH 04/15 6.6.y] minmax: make generic MIN() and MAX() macros available everywhere Eliav Farber
2025-09-22 12:27 ` Patch "minmax: make generic MIN() and MAX() macros available everywhere" has been added to the 6.6-stable tree gregkh
2025-09-22 12:27 ` gregkh
2025-09-22 12:27 ` gregkh
2025-09-22 12:40 ` Greg KH
2025-09-22 10:32 ` [PATCH 05/15 6.6.y] minmax: simplify min()/max()/clamp() implementation Eliav Farber
2025-09-22 12:27 ` Patch "minmax: simplify min()/max()/clamp() implementation" has been added to the 6.6-stable tree gregkh
2025-09-22 12:27 ` gregkh
2025-09-22 12:27 ` gregkh
2025-09-22 10:32 ` [PATCH 06/15 6.6.y] minmax: don't use max() in situations that want a C constant expression Eliav Farber
2025-09-22 12:26 ` Patch "minmax: don't use max() in situations that want a C constant expression" has been added to the 6.6-stable tree gregkh
2025-09-22 12:26 ` gregkh
2025-09-22 12:26 ` gregkh
2025-09-22 10:32 ` [PATCH 07/15 6.6.y] minmax: improve macro expansion and type checking Eliav Farber
2025-09-22 12:26 ` Patch "minmax: improve macro expansion and type checking" has been added to the 6.6-stable tree gregkh
2025-09-22 12:26 ` gregkh
2025-09-22 12:26 ` gregkh
2025-09-22 10:32 ` [PATCH 08/15 6.6.y] minmax: fix up min3() and max3() too Eliav Farber
2025-09-22 12:26 ` Patch "minmax: fix up min3() and max3() too" has been added to the 6.6-stable tree gregkh
2025-09-22 12:26 ` gregkh
2025-09-22 12:26 ` gregkh
2025-09-22 10:32 ` [PATCH 09/15 6.6.y] minmax.h: add whitespace around operators and after commas Eliav Farber
2025-09-22 10:32 ` [PATCH 10/15 6.6.y] minmax.h: update some comments Eliav Farber
2025-09-22 10:32 ` [PATCH 11/15 6.6.y] minmax.h: reduce the #define expansion of min(), max() and clamp() Eliav Farber
2025-09-22 10:32 ` [PATCH 12/15 6.6.y] minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp() Eliav Farber
2025-09-22 10:32 ` [PATCH 13/15 6.6.y] minmax.h: move all the clamp() definitions after the min/max() ones Eliav Farber
2025-09-22 10:32 ` [PATCH 14/15 6.6.y] minmax.h: simplify the variants of clamp() Eliav Farber
2025-09-22 10:32 ` [PATCH 15/15 6.6.y] minmax.h: remove some #defines that are only expanded once Eliav Farber
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=20250922103241.16213-4-farbere@amazon.com \
--to=farbere@amazon.com \
--cc=David.Laight@ACULAB.COM \
--cc=Rodrigo.Siqueira@amd.com \
--cc=Xinhui.Pan@amd.com \
--cc=agk@redhat.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.deucher@amd.com \
--cc=alexandre.torgue@foss.st.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=anton.ivanov@cambridgegreys.com \
--cc=arnd@kernel.org \
--cc=artur.paszkiewicz@intel.com \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=christian.koenig@amd.com \
--cc=clm@fb.com \
--cc=daniel@ffwll.ch \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dm-devel@lists.linux.dev \
--cc=dmitry.torokhov@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=dsahern@kernel.org \
--cc=dsterba@suse.com \
--cc=edumazet@google.com \
--cc=evan.quan@amd.com \
--cc=gregkh@linuxfoundation.org \
--cc=harry.wentland@amd.com \
--cc=hdegoede@redhat.com \
--cc=hpa@zytor.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=james.morse@arm.com \
--cc=jdelvare@suse.com \
--cc=jejb@linux.ibm.com \
--cc=jernej.skrabec@gmail.com \
--cc=joabreu@synopsys.com \
--cc=johannes@sipsolutions.net \
--cc=josef@toxicpanda.com \
--cc=keescook@chromium.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-sunxi@lists.linux.dev \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=linux@rasmusvillemoes.dk \
--cc=linux@roeck-us.net \
--cc=lorenzo.stoakes@oracle.com \
--cc=luc.vanoostenryck@gmail.com \
--cc=luto@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mailhol.vincent@wanadoo.fr \
--cc=malattia@linux.it \
--cc=markgross@kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mchehab@kernel.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=mhiramat@kernel.org \
--cc=minchan@kernel.org \
--cc=mingo@redhat.com \
--cc=mkl@pengutronix.de \
--cc=mripard@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=peterz@infradead.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=qiuxu.zhuo@intel.com \
--cc=richard@nod.at \
--cc=rostedt@goodmis.org \
--cc=rric@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=samuel@sholland.org \
--cc=senozhatsky@chromium.org \
--cc=shuah@kernel.org \
--cc=snitzer@kernel.org \
--cc=stable@vger.kernel.org \
--cc=sunpeng.li@amd.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=tzimmermann@suse.de \
--cc=wad@chromium.org \
--cc=wens@csie.org \
--cc=wg@grandegger.com \
--cc=x86@kernel.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.