public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Eliav Farber <farbere@amazon.com>
Cc: sashal@kernel.org, mario.limonciello@amd.com, lijo.lazar@amd.com,
	David.Laight@aculab.com, arnd@kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Subject: Re: [PATCH v2 03/13 6.1.y] minmax: simplify min()/max()/clamp() implementation
Date: Tue, 30 Sep 2025 16:25:28 +0200	[thread overview]
Message-ID: <2025093026-gutter-avert-7f16@gregkh> (raw)
In-Reply-To: <20250929183358.18982-4-farbere@amazon.com>

On Mon, Sep 29, 2025 at 06:33:48PM +0000, Eliav Farber wrote:
> From: Linus Torvalds <torvalds@linux-foundation.org>
> 
> [ Upstream commit dc1c8034e31b14a2e5e212104ec508aec44ce1b9 ]
> 
> Now that we no longer have any C constant expression contexts (ie array
> size declarations or static initializers) that use min() or max(), we
> can simpify the implementation by not having to worry about the result
> staying as a C constant expression.
> 
> So now we can unconditionally just use temporary variables of the right
> type, and get rid of the excessive expansion that used to come from the
> use of
> 
>    __builtin_choose_expr(__is_constexpr(...), ..
> 
> to pick the specialized code for constant expressions.
> 
> Another expansion simplification is to pass the temporary variables (in
> addition to the original expression) to our __types_ok() macro.  That
> may superficially look like it complicates the macro, but when we only
> want the type of the expression, expanding the temporary variable names
> is much simpler and smaller than expanding the potentially complicated
> original expression.
> 
> As a result, on my machine, doing a
> 
>   $ time make drivers/staging/media/atomisp/pci/isp/kernels/ynr/ynr_1.0/ia_css_ynr.host.i
> 
> goes from
> 
> 	real	0m16.621s
> 	user	0m15.360s
> 	sys	0m1.221s
> 
> to
> 
> 	real	0m2.532s
> 	user	0m2.091s
> 	sys	0m0.452s
> 
> because the token expansion goes down dramatically.
> 
> In particular, the longest line expansion (which was line 71 of that
> 'ia_css_ynr.host.c' file) shrinks from 23,338kB (yes, 23MB for one
> single line) to "just" 1,444kB (now "only" 1.4MB).
> 
> And yes, that line is still the line from hell, because it's doing
> multiple levels of "min()/max()" expansion thanks to some of them being
> hidden inside the uDIGIT_FITTING() macro.
> 
> Lorenzo has a nice cleanup patch that makes that driver use inline
> functions instead of macros for sDIGIT_FITTING() and uDIGIT_FITTING(),
> which will fix that line once and for all, but the 16-fold reduction in
> this case does show why we need to simplify these helpers.
> 
> 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>
> ---
>  include/linux/minmax.h | 43 ++++++++++++++++++++----------------------
>  1 file changed, 20 insertions(+), 23 deletions(-)

This change breaks the build in drivers/md/ :

In file included from ./include/linux/container_of.h:5,
                 from ./include/linux/list.h:5,
                 from ./include/linux/wait.h:7,
                 from ./include/linux/mempool.h:8,
                 from ./include/linux/bio.h:8,
                 from drivers/md/dm-bio-record.h:10,
                 from drivers/md/dm-integrity.c:9:
drivers/md/dm-integrity.c: In function ‘integrity_metadata’:
drivers/md/dm-integrity.c:131:105: error: ISO C90 forbids variable length array ‘checksums_onstack’ [-Werror=vla]
  131 | #define MAX_TAG_SIZE                    (JOURNAL_SECTOR_DATA - JOURNAL_MAC_PER_SECTOR - offsetof(struct journal_entry, last_bytes[MAX_SECTORS_PER_BLOCK]))
      |                                                                                                         ^~~~~~~~~~~~~
./include/linux/build_bug.h:78:56: note: in definition of macro ‘__static_assert’
   78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
      |                                                        ^~~~
./include/linux/minmax.h:56:9: note: in expansion of macro ‘static_assert’
   56 |         static_assert(__types_ok(x, y, ux, uy),         \
      |         ^~~~~~~~~~~~~
./include/linux/minmax.h:41:31: note: in expansion of macro ‘__is_noneg_int’
   41 |          __is_noneg_int(x) || __is_noneg_int(y))
      |                               ^~~~~~~~~~~~~~
./include/linux/minmax.h:56:23: note: in expansion of macro ‘__types_ok’
   56 |         static_assert(__types_ok(x, y, ux, uy),         \
      |                       ^~~~~~~~~~
./include/linux/minmax.h:61:9: note: in expansion of macro ‘__careful_cmp_once’
   61 |         __careful_cmp_once(op, x, y, __UNIQUE_ID(x_), __UNIQUE_ID(y_))
      |         ^~~~~~~~~~~~~~~~~~
./include/linux/minmax.h:92:25: note: in expansion of macro ‘__careful_cmp’
   92 | #define max(x, y)       __careful_cmp(max, x, y)
      |                         ^~~~~~~~~~~~~
drivers/md/dm-integrity.c:1797:40: note: in expansion of macro ‘max’
 1797 |                 char checksums_onstack[max((size_t)HASH_MAX_DIGESTSIZE, MAX_TAG_SIZE)];
      |                                        ^~~
drivers/md/dm-integrity.c:131:89: note: in expansion of macro ‘offsetof’
  131 | #define MAX_TAG_SIZE                    (JOURNAL_SECTOR_DATA - JOURNAL_MAC_PER_SECTOR - offsetof(struct journal_entry, last_bytes[MAX_SECTORS_PER_BLOCK]))
      |                                                                                         ^~~~~~~~
drivers/md/dm-integrity.c:1797:73: note: in expansion of macro ‘MAX_TAG_SIZE’
 1797 |                 char checksums_onstack[max((size_t)HASH_MAX_DIGESTSIZE, MAX_TAG_SIZE)];
      |                                                                         ^~~~~~~~~~~~


So I'll stop here on this series.

After the next release, can you rebase the series and resend the remaining ones after they are fixed up to build properly?

thanks,

greg k-h

  reply	other threads:[~2025-09-30 14:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-29 18:33 [PATCH v2 00/13 6.1.y] Backport minmax.h updates from v6.17-rc7 Eliav Farber
2025-09-29 18:33 ` [PATCH v2 01/13 6.1.y] minmax: make generic MIN() and MAX() macros available everywhere Eliav Farber
2025-09-29 18:33 ` [PATCH v2 02/13 6.1.y] minmax: add a few more MIN_T/MAX_T users Eliav Farber
2025-09-29 18:33 ` [PATCH v2 03/13 6.1.y] minmax: simplify min()/max()/clamp() implementation Eliav Farber
2025-09-30 14:25   ` Greg KH [this message]
2025-09-30 14:49     ` Farber, Eliav
2025-09-29 18:33 ` [PATCH v2 04/13 6.1.y] minmax: don't use max() in situations that want a C constant expression Eliav Farber
2025-09-29 18:33 ` [PATCH v2 05/13 6.1.y] minmax: improve macro expansion and type checking Eliav Farber
2025-09-29 18:33 ` [PATCH v2 06/13 6.1.y] minmax: fix up min3() and max3() too Eliav Farber
2025-09-29 18:33 ` [PATCH v2 07/13 6.1.y] minmax.h: add whitespace around operators and after commas Eliav Farber
2025-09-29 18:33 ` [PATCH v2 08/13 6.1.y] minmax.h: update some comments Eliav Farber
2025-09-29 18:33 ` [PATCH v2 09/13 6.1.y] minmax.h: reduce the #define expansion of min(), max() and clamp() Eliav Farber
2025-09-29 18:33 ` [PATCH v2 10/13 6.1.y] minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp() Eliav Farber
2025-09-29 18:33 ` [PATCH v2 11/13 6.1.y] minmax.h: move all the clamp() definitions after the min/max() ones Eliav Farber
2025-09-29 18:33 ` [PATCH v2 12/13 6.1.y] minmax.h: simplify the variants of clamp() Eliav Farber
2025-09-29 18:33 ` [PATCH v2 13/13 6.1.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=2025093026-gutter-avert-7f16@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=David.Laight@aculab.com \
    --cc=arnd@kernel.org \
    --cc=farbere@amazon.com \
    --cc=lijo.lazar@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mario.limonciello@amd.com \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox