[Linux-stm32] Patch "minmax: avoid overly complicated constant expressions in VM code" has been added to the 6.1-stable tree

[gregkh at linuxfoundation.org]

This is a note to let you know that I've just added the patch titled

    minmax: avoid overly complicated constant expressions in VM code

to the 6.1-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     minmax-avoid-overly-complicated-constant-expressions-in-vm-code.patch
and it can be found in the queue-6.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable at vger.kernel.org> know about it.


>From linux-staging+bounces-34579-greg=kroah.com at lists.linux.dev Wed Sep 24 22:28:45 2025
From: Eliav Farber <farbere at amazon.com>
Date: Wed, 24 Sep 2025 20:23:06 +0000
Subject: minmax: avoid overly complicated constant expressions in VM code
To: <linux at armlinux.org.uk>, <richard at nod.at>, <anton.ivanov at cambridgegreys.com>, <johannes at sipsolutions.net>, <dave.hansen at linux.intel.com>, <luto at kernel.org>, <peterz at infradead.org>, <tglx at linutronix.de>, <mingo at redhat.com>, <bp at alien8.de>, <x86 at kernel.org>, <hpa at zytor.com>, <tony.luck at intel.com>, <qiuxu.zhuo at intel.com>, <mchehab at kernel.org>, <james.morse at arm.com>, <rric at kernel.org>, <harry.wentland at amd.com>, <sunpeng.li at amd.com>, <Rodrigo.Siqueira at amd.com>, <alexander.deucher at amd.com>, <christian.koenig at amd.com>, <Xinhui.Pan at amd.com>, <airlied at gmail.com>, <daniel at ffwll.ch>, <evan.quan at amd.com>, <james.qian.wang at arm.com>, <liviu.dudau at arm.com>, <mihail.atanassov at arm.com>, <brian.starkey at arm.com>, <maarten.lankhorst at linux.intel.com>, <mripard at kernel.org>, <tzimmermann at suse.de>, <robdclark at gmail.com>, <quic_abhinavk at quicinc.com>, <dmitry.baryshkov at linaro.org>, <sean at poorly.run>, <jdelvare at suse.com>, <linux at roeck-us.net>, <linus.walleij at linaro.org>, <dmitry.torokhov at gmail.com>, <maz at k
 ernel.org>, <wens at csie.org>, <jernej.skrabec at gmail.com>, <samuel at sholland.org>, <agk at redhat.com>, <snitzer at kernel.org>, <dm-devel at redhat.com>, <rajur at chelsio.com>, <davem at davemloft.net>, <edumazet at google.com>, <kuba at kernel.org>, <pabeni at redhat.com>, <peppe.cavallaro at st.com>, <alexandre.torgue at foss.st.com>, <joabreu at synopsys.com>, <mcoquelin.stm32 at gmail.com>, <krzysztof.kozlowski at linaro.org>, <malattia at linux.it>, <hdegoede at redhat.com>, <markgross at kernel.org>, <artur.paszkiewicz at intel.com>, <jejb at linux.ibm.com>, <martin.petersen at oracle.com>, <sakari.ailus at linux.intel.com>, <gregkh at linuxfoundation.org>, <fei1.li at intel.com>, <clm at fb.com>, <josef at toxicpanda.com>, <dsterba at suse.com>, <jack at suse.com>, <tytso at mit.edu>, <adilger.kernel at dilger.ca>, <dushistov at mail.ru>, <luc.vanoostenryck at gmail.com>, <rostedt at goodmis.org>, <mhiramat at kernel.org>, <pmladek at suse.com>, <senozhatsky at chromium.org>, <andriy.shevchenko at linux.intel.com>, <linux at rasmusvillemoes.dk>, <minchan at kernel.org>, <ngupta at vflare.
 org>, <akpm at linux-foundation.org>, <yoshfuji at linux-ipv6.org>, <dsahern at kernel.org>, <pablo at netfilter.org>, <kadlec at netfilter.org>, <fw at strlen.de>, <jmaloy at redhat.com>, <ying.xue at windriver.com>, <andrii at kernel.org>, <mykolal at fb.com>, <ast at kernel.org>, <daniel at iogearbox.net>, <martin.lau at linux.dev>, <song at kernel.org>, <yhs at fb.com>, <john.fastabend at gmail.com>, <kpsingh at kernel.org>, <sdf at google.com>, <haoluo at google.com>, <jolsa at kernel.org>, <shuah at kernel.org>, <keescook at chromium.org>, <wad at chromium.org>, <willy at infradead.org>, <farbere at amazon.com>, <sashal at kernel.org>, <ruanjinjie at huawei.com>, <quic_akhilpo at quicinc.com>, <David.Laight at ACULAB.COM>, <herve.codina at bootlin.com>, <linux-arm-kernel at lists.infradead.org>, <linux-kernel at vger.kernel.org>, <linux-um at lists.infradead.org>, <linux-edac at vger.kernel.org>, <amd-gfx at lists.freedesktop.org>, <dri-devel at lists.freedesktop.org>, <linux-arm-msm at vger.kernel.org>, <freedreno at lists.freedesktop.org>, <linux-hwmon at vger.kernel.org>, <linux-input at vge
 r.kernel.org>, <linux-sunxi at lists.linux.dev>, <linux-media at vger.kernel.org>, <netdev at vger.kernel.org>, <linux-stm32 at st-md-mailman.stormreply.com>, <platform-driver-x86 at vger.kernel.org>, <linux-scsi at vger.kernel.org>, <linux-staging at lists.linux.dev>, <linux-btrfs at vger.kernel.org>, <linux-ext4 at vger.kernel.org>, <linux-sparse at vger.kernel.org>, <linux-mm at kvack.org>, <netfilter-devel at vger.kernel.org>, <coreteam at netfilter.org>, <tipc-discussion at lists.sourceforge.net>, <bpf at vger.kernel.org>, <linux-kselftest at vger.kernel.org>, <stable at vger.kernel.org>
Cc: Linus Torvalds <torvalds at linux-foundation.org>, Lorenzo Stoakes <lorenzo.stoakes at oracle.com>, David Laight <David.Laight at aculab.com>
Message-ID: <20250924202320.32333-6-farbere at amazon.com>

From: Linus Torvalds <torvalds at linux-foundation.org>

[ Upstream commit 3a7e02c040b130b5545e4b115aada7bacd80a2b6 ]

The minmax infrastructure is overkill for simple constants, and can
cause huge expansions because those simple constants are then used by
other things.

For example, 'pageblock_order' is a core VM constant, but because it was
implemented using 'min_t()' and all the type-checking that involves, it
actually expanded to something like 2.5kB of preprocessor noise.

And when that simple constant was then used inside other expansions:

  #define pageblock_nr_pages      (1UL << pageblock_order)
  #define pageblock_start_pfn(pfn)  ALIGN_DOWN((pfn), pageblock_nr_pages)

and we then use that inside a 'max()' macro:

	case ISOLATE_SUCCESS:
		update_cached = false;
		last_migrated_pfn = max(cc->zone->zone_start_pfn,
			pageblock_start_pfn(cc->migrate_pfn - 1));

the end result was that one statement expanding to 253kB in size.

There are probably other cases of this, but this one case certainly
stood out.

I've added 'MIN_T()' and 'MAX_T()' macros for this kind of "core simple
constant with specific type" use.  These macros skip the type checking,
and as such need to be very sparingly used only for obvious cases that
have active issues like this.

Reported-by: Lorenzo Stoakes <lorenzo.stoakes at oracle.com>
Link: https://lore.kernel.org/all/36aa2cad-1db1-4abf-8dd2-fb20484aabc3@lucifer.local/
Cc: David Laight <David.Laight at aculab.com>
Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
Signed-off-by: Eliav Farber <farbere at amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 include/linux/minmax.h          |    7 +++++++
 include/linux/pageblock-flags.h |    2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

--- a/include/linux/minmax.h
+++ b/include/linux/minmax.h
@@ -270,4 +270,11 @@ static inline bool in_range32(u32 val, u
 #define swap(a, b) \
 	do { typeof(a) __tmp = (a); (a) = (b); (b) = __tmp; } while (0)
 
+/*
+ * Use these carefully: no type checking, and uses the arguments
+ * multiple times. Use for obvious constants only.
+ */
+#define MIN_T(type,a,b) __cmp(min,(type)(a),(type)(b))
+#define MAX_T(type,a,b) __cmp(max,(type)(a),(type)(b))
+
 #endif	/* _LINUX_MINMAX_H */
--- a/include/linux/pageblock-flags.h
+++ b/include/linux/pageblock-flags.h
@@ -41,7 +41,7 @@ extern unsigned int pageblock_order;
  * Huge pages are a constant size, but don't exceed the maximum allocation
  * granularity.
  */
-#define pageblock_order		min_t(unsigned int, HUGETLB_PAGE_ORDER, MAX_ORDER - 1)
+#define pageblock_order		MIN_T(unsigned int, HUGETLB_PAGE_ORDER, MAX_ORDER - 1)
 
 #endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
 


Patches currently in stable-queue which might be from farbere at amazon.com are

queue-6.1/minmax-add-a-few-more-min_t-max_t-users.patch
queue-6.1/minmax-fix-indentation-of-__cmp_once-and-__clamp_once.patch
queue-6.1/minmax-add-in_range-macro.patch
queue-6.1/minmax-deduplicate-__unconst_integer_typeof.patch
queue-6.1/minmax-simplify-and-clarify-min_t-max_t-implementation.patch
queue-6.1/minmax-avoid-overly-complicated-constant-expressions-in-vm-code.patch
queue-6.1/minmax-introduce-min-max-_array.patch