Blame SOURCES/0481-ieee1275-drop-HEAP_MAX_ADDR-HEAP_MIN_SIZE.patch

f20682
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
f20682
From: Daniel Axtens <dja@axtens.net>
f20682
Date: Wed, 14 Apr 2021 20:10:23 +1000
f20682
Subject: [PATCH] ieee1275: drop HEAP_MAX_ADDR, HEAP_MIN_SIZE
f20682
f20682
HEAP_MAX_ADDR is confusing. Currently it is set to 32MB, except
f20682
on ieee1275 on x86, where it is 64MB.
f20682
f20682
There is a comment which purports to explain it:
f20682
f20682
/* If possible, we will avoid claiming heap above this address, because it
f20682
   seems to cause relocation problems with OSes that link at 4 MiB */
f20682
f20682
This doesn't make a lot of sense when the constants are well above 4MB
f20682
already. It was not always this way. Prior to
f20682
commit 7b5d0fe4440c ("Increase heap limit") in 2010, HEAP_MAX_SIZE and
f20682
HEAP_MAX_ADDR were indeed 4MB. However, when the constants were increased
f20682
the comment was left unchanged.
f20682
f20682
It's been over a decade. It doesn't seem like we have problems with
f20682
claims over 4MB on powerpc or x86 ieee1275. (sparc does things completely
f20682
differently and never used the constant.)
f20682
f20682
Drop the constant and the check.
f20682
f20682
The only use of HEAP_MIN_SIZE was to potentially override the
f20682
HEAP_MAX_ADDR check. It is now unused. Remove it.
f20682
f20682
Signed-off-by: Daniel Axtens <dja@axtens.net>
f20682
---
f20682
 grub-core/kern/ieee1275/init.c | 17 -----------------
f20682
 1 file changed, 17 deletions(-)
f20682
f20682
diff --git a/grub-core/kern/ieee1275/init.c b/grub-core/kern/ieee1275/init.c
b32e65
index 22dc3013d..ee97d761d 100644
f20682
--- a/grub-core/kern/ieee1275/init.c
f20682
+++ b/grub-core/kern/ieee1275/init.c
f20682
@@ -42,9 +42,6 @@
f20682
 #include <grub/machine/kernel.h>
f20682
 #endif
f20682
 
f20682
-/* The minimal heap size we can live with. */
f20682
-#define HEAP_MIN_SIZE		(unsigned long) (2 * 1024 * 1024)
f20682
-
f20682
 /* The maximum heap size we're going to claim */
f20682
 #ifdef __i386__
f20682
 #define HEAP_MAX_SIZE		(unsigned long) (64 * 1024 * 1024)
f20682
@@ -52,14 +49,6 @@
f20682
 #define HEAP_MAX_SIZE		(unsigned long) (32 * 1024 * 1024)
f20682
 #endif
f20682
 
f20682
-/* If possible, we will avoid claiming heap above this address, because it
f20682
-   seems to cause relocation problems with OSes that link at 4 MiB */
f20682
-#ifdef __i386__
f20682
-#define HEAP_MAX_ADDR		(unsigned long) (64 * 1024 * 1024)
f20682
-#else
f20682
-#define HEAP_MAX_ADDR		(unsigned long) (32 * 1024 * 1024)
f20682
-#endif
f20682
-
f20682
 extern char _end[];
f20682
 
f20682
 #ifdef __sparc__
f20682
@@ -181,12 +170,6 @@ heap_init (grub_uint64_t addr, grub_uint64_t len, grub_memory_type_t type,
f20682
   if (*total + len > HEAP_MAX_SIZE)
f20682
     len = HEAP_MAX_SIZE - *total;
f20682
 
f20682
-  /* Avoid claiming anything above HEAP_MAX_ADDR, if possible. */
f20682
-  if ((addr < HEAP_MAX_ADDR) &&				/* if it's too late, don't bother */
f20682
-      (addr + len > HEAP_MAX_ADDR) &&				/* if it wasn't available anyway, don't bother */
f20682
-      (*total + (HEAP_MAX_ADDR - addr) > HEAP_MIN_SIZE))	/* only limit ourselves when we can afford to */
f20682
-     len = HEAP_MAX_ADDR - addr;
f20682
-
f20682
   /* In theory, firmware should already prevent this from happening by not
f20682
      listing our own image in /memory/available.  The check below is intended
f20682
      as a safeguard in case that doesn't happen.  However, it doesn't protect