Message-ID: <20250919101727.16152-13-farbere@amazon.com>
Date: Fri, 19 Sep 2025 10:17:12 +0000
From: Eliav Farber <farbere@...zon.com>
To: <linux@...linux.org.uk>, <jdike@...toit.com>, <richard@....at>,
	<anton.ivanov@...bridgegreys.com>, <dave.hansen@...ux.intel.com>,
	<luto@...nel.org>, <peterz@...radead.org>, <tglx@...utronix.de>,
	<mingo@...hat.com>, <bp@...en8.de>, <x86@...nel.org>, <hpa@...or.com>,
	<tony.luck@...el.com>, <qiuxu.zhuo@...el.com>, <mchehab@...nel.org>,
	<james.morse@....com>, <rric@...nel.org>, <harry.wentland@....com>,
	<sunpeng.li@....com>, <alexander.deucher@....com>,
	<christian.koenig@....com>, <airlied@...ux.ie>, <daniel@...ll.ch>,
	<evan.quan@....com>, <james.qian.wang@....com>, <liviu.dudau@....com>,
	<mihail.atanassov@....com>, <brian.starkey@....com>,
	<maarten.lankhorst@...ux.intel.com>, <mripard@...nel.org>,
	<tzimmermann@...e.de>, <robdclark@...il.com>, <sean@...rly.run>,
	<jdelvare@...e.com>, <linux@...ck-us.net>, <fery@...ress.com>,
	<dmitry.torokhov@...il.com>, <agk@...hat.com>, <snitzer@...hat.com>,
	<dm-devel@...hat.com>, <rajur@...lsio.com>, <davem@...emloft.net>,
	<kuba@...nel.org>, <peppe.cavallaro@...com>, <alexandre.torgue@...com>,
	<joabreu@...opsys.com>, <mcoquelin.stm32@...il.com>, <malattia@...ux.it>,
	<hdegoede@...hat.com>, <mgross@...ux.intel.com>, <intel-linux-scu@...el.com>,
	<artur.paszkiewicz@...el.com>, <jejb@...ux.ibm.com>,
	<martin.petersen@...cle.com>, <sakari.ailus@...ux.intel.com>,
	<gregkh@...uxfoundation.org>, <clm@...com>, <josef@...icpanda.com>,
	<dsterba@...e.com>, <jack@...e.com>, <tytso@....edu>,
	<adilger.kernel@...ger.ca>, <dushistov@...l.ru>,
	<luc.vanoostenryck@...il.com>, <rostedt@...dmis.org>, <pmladek@...e.com>,
	<sergey.senozhatsky@...il.com>, <andriy.shevchenko@...ux.intel.com>,
	<linux@...musvillemoes.dk>, <minchan@...nel.org>, <ngupta@...are.org>,
	<akpm@...ux-foundation.org>, <kuznet@....inr.ac.ru>,
	<yoshfuji@...ux-ipv6.org>, <pablo@...filter.org>, <kadlec@...filter.org>,
	<fw@...len.de>, <jmaloy@...hat.com>, <ying.xue@...driver.com>,
	<willy@...radead.org>, <farbere@...zon.com>, <sashal@...nel.org>,
	<ruanjinjie@...wei.com>, <David.Laight@...LAB.COM>,
	<herve.codina@...tlin.com>, <Jason@...c4.com>, <bvanassche@....org>,
	<keescook@...omium.org>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, <linux-um@...ts.infradead.org>,
	<linux-edac@...r.kernel.org>, <amd-gfx@...ts.freedesktop.org>,
	<dri-devel@...ts.freedesktop.org>, <linux-arm-msm@...r.kernel.org>,
	<freedreno@...ts.freedesktop.org>, <linux-hwmon@...r.kernel.org>,
	<linux-input@...r.kernel.org>, <linux-media@...r.kernel.org>,
	<netdev@...r.kernel.org>, <linux-stm32@...md-mailman.stormreply.com>,
	<platform-driver-x86@...r.kernel.org>, <linux-scsi@...r.kernel.org>,
	<linux-staging@...ts.linux.dev>, <linux-btrfs@...r.kernel.org>,
	<linux-ext4@...r.kernel.org>, <linux-sparse@...r.kernel.org>,
	<linux-mm@...ck.org>, <netfilter-devel@...r.kernel.org>,
	<coreteam@...filter.org>, <tipc-discussion@...ts.sourceforge.net>,
	<stable@...r.kernel.org>
CC: <jonnyc@...zon.com>, Linus Torvalds <torvalds@...ux-foundation.org>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, David Laight
	<David.Laight@...lab.com>
Subject: [PATCH 12/27 5.10.y] minmax: avoid overly complicated constant expressions in VM code

From: Linus Torvalds <torvalds@...ux-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@...cle.com>
Link: https://lore.kernel.org/all/36aa2cad-1db1-4abf-8dd2-fb20484aabc3@lucifer.local/
Cc: David Laight <David.Laight@...lab.com>
Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
Signed-off-by: Eliav Farber <farbere@...zon.com>
---
 include/linux/minmax.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/minmax.h b/include/linux/minmax.h
index 2ec559284a9f..a7ef65f78933 100644
--- a/include/linux/minmax.h
+++ b/include/linux/minmax.h
@@ -270,4 +270,11 @@ static inline bool in_range32(u32 val, u32 start, u32 len)
 #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 */
-- 
2.47.3

Powered by blists - more mailing lists