|
 |
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
|