Patch "minmax: avoid overly complex min()/max() macro arguments in xen" has been added to the 4.19-stable tree

[Sasha Levin <sashal@xxxxxxxxxx>]

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

    minmax: avoid overly complex min()/max() macro arguments in xen

to the 4.19-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-complex-min-max-macro-arguments-.patch
and it can be found in the queue-4.19 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 67040aee5f7d6230e3d41bce54fa185fc6918a57
Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date:   Fri Jul 26 15:09:07 2024 -0700

    minmax: avoid overly complex min()/max() macro arguments in xen
    
    [ Upstream commit e8432ac802a028eaee6b1e86383d7cd8e9fb8431 ]
    
    We have some very fancy min/max macros that have tons of sanity checking
    to warn about mixed signedness etc.
    
    This is all things that a sane compiler should warn about, but there are
    no sane compiler interfaces for this, and '-Wsign-compare' is broken [1]
    and not useful.
    
    So then we compensate (some would say over-compensate) by doing the
    checks manually with some truly horrid macro games.
    
    And no, we can't just use __builtin_types_compatible_p(), because the
    whole question of "does it make sense to compare these two values" is a
    lot more complicated than that.
    
    For example, it makes a ton of sense to compare unsigned values with
    simple constants like "5", even if that is indeed a signed type.  So we
    have these very strange macros to try to make sensible type checking
    decisions on the arguments to 'min()' and 'max()'.
    
    But that can cause enormous code expansion if the min()/max() macros are
    used with complicated expressions, and particularly if you nest these
    things so that you get the first big expansion then expanded again.
    
    The xen setup.c file ended up ballooning to over 50MB of preprocessed
    noise that takes 15s to compile (obviously depending on the build host),
    largely due to one single line.
    
    So let's split that one single line to just be simpler.  I think it ends
    up being more legible to humans too at the same time.  Now that single
    file compiles in under a second.
    
    Reported-and-reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
    Link: https://lore.kernel.org/all/c83c17bb-be75-4c67-979d-54eee38774c6@lucifer.local/
    Link: https://staticthinking.wordpress.com/2023/07/25/wsign-compare-is-garbage/ [1]
    Cc: David Laight <David.Laight@xxxxxxxxxx>
    Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
    Stable-dep-of: be35d91c8880 ("xen: tolerate ACPI NVS memory overlapping with Xen allocated memory")
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 69fd1134b7fcf..ad69e5796cd0c 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -737,6 +737,7 @@ char * __init xen_memory_setup(void)
 	struct xen_memory_map memmap;
 	unsigned long max_pages;
 	unsigned long extra_pages = 0;
+	unsigned long maxmem_pages;
 	int i;
 	int op;
 
@@ -802,8 +803,8 @@ char * __init xen_memory_setup(void)
 	 * the initial memory is also very large with respect to
 	 * lowmem, but we won't try to deal with that here.
 	 */
-	extra_pages = min3(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)),
-			   extra_pages, max_pages - max_pfn);
+	maxmem_pages = EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM));
+	extra_pages = min3(maxmem_pages, extra_pages, max_pages - max_pfn);
 	i = 0;
 	addr = xen_e820_table.entries[0].addr;
 	size = xen_e820_table.entries[0].size;