public inbox for git-commits@fedoraproject.org
help / color / mirror / Atom feed
From: Leo Sandoval <lsandova@redhat.com>
To: git-commits@fedoraproject.org
Subject: [rpms/grub2] rawhide: mm: try allocating regions above defined limit as last resource
Date: Wed, 08 Jul 2026 17:01:46 GMT	[thread overview]
Message-ID: <178353010681.1.7825171472897023635.rpms-grub2-c30c865bf1b5@fedoraproject.org> (raw)

            A new commit has been pushed.

            Repo   : rpms/grub2
            Branch : rawhide
            Commit : c30c865bf1b56cbbf8c38c5739303dafe0bb64ed
            Author : Leo Sandoval <lsandova@redhat.com>
            Date   : 2026-07-07T12:08:46-06:00
            Stats  : +158/-2 in 3 file(s)
            URL    : https://src.fedoraproject.org/rpms/grub2/c/c30c865bf1b56cbbf8c38c5739303dafe0bb64ed?branch=rawhide

            Log:
            mm: try allocating regions above defined limit as last resource

As indicated on the patch, this new approach tries allocating regions
above defined limit with the hope of getting large regions so
allocations can fit but it may impact some systems where DMA is done
wrong on these regions.

This change also reverts the previous approach f3330b6c where
verifiers use direct EFI pages to allocate memory but had several
implications as indicated on the ticket references.

Resolves: #2263643
Related: #2427945
Related: #2422881
Related: #2453022
Related: #2451630
Related: #2450672

Signed-off-by: Leo Sandoval <lsandova@redhat.com>

---
diff --git a/0446-mm-try-allocating-regions-above-defined-limit-as-las.patch b/0446-mm-try-allocating-regions-above-defined-limit-as-las.patch
new file mode 100644
index 0000000..2714077
--- /dev/null
+++ b/0446-mm-try-allocating-regions-above-defined-limit-as-las.patch
@@ -0,0 +1,146 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Leo Sandoval <lsandova@redhat.com>
+Date: Fri, 26 Jun 2026 15:14:37 -0600
+Subject: [PATCH] mm: try allocating regions above defined limit as last
+ resource
+
+This is yet another approach to overcome out-of-memory issues on those
+systems with constrained and fragmented EFI memories, where large files,
+e.g. initrd, which may cause out-of-memory errors stopping the boot process.
+
+This time, the approach is not to hardcode the
+maximum (GRUB_EFI_MAX_ALLOCATION_ADDRESS=2^64-1) but instead increase
+the filtering range to include EFI's conventional memory above
+GRUB_EFI_MAX_ALLOCATION_ADDRESS (2GB).
+
+Conceptually this is the same as increasing
+GRUB_EFI_MAX_ALLOCATION_ADDRESS to 2^64-1 but this time the memory
+allocator  algorithm is a bit smarter: it first tries current
+allocation methods below GRUB_EFI_MAX_ALLOCATION_ADDRESS, not
+impacting current boots and if fails, it tries above this value.
+
+This is not a silver-buller for all firmware types: there may be some
+machines with constrained and fragmented memories besides with firmware
+drivers which cannot properly DMA above
+GRUB_EFI_MAX_ALLOCATION_ADDRESS, where although no OOM issues are
+seeing, boot can fail in other areas. On these particular systems,
+there is not much GRUB can do.
+
+Signed-off-by: Leo Sandoval <lsandova@redhat.com>
+---
+ grub-core/kern/efi/mm.c | 22 +++++++++++++---------
+ grub-core/kern/mm.c     | 25 +++++++++++++++++++++++--
+ include/grub/mm.h       |  1 +
+ 3 files changed, 37 insertions(+), 11 deletions(-)
+
+diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
+index 464fe1c3c..22a936a6e 100644
+--- a/grub-core/kern/efi/mm.c
++++ b/grub-core/kern/efi/mm.c
+@@ -470,10 +470,12 @@ static grub_efi_memory_descriptor_t *
+ filter_memory_map (grub_efi_memory_descriptor_t *memory_map,
+ 		   grub_efi_memory_descriptor_t *filtered_memory_map,
+ 		   grub_efi_uintn_t desc_size,
+-		   grub_efi_memory_descriptor_t *memory_map_end)
++		   grub_efi_memory_descriptor_t *memory_map_end,
++		   unsigned int flags)
+ {
+   grub_efi_memory_descriptor_t *desc;
+   grub_efi_memory_descriptor_t *filtered_desc;
++  unsigned int no_limit = flags & GRUB_MM_ADD_REGION_NO_LIMIT;
+ 
+   for (desc = memory_map, filtered_desc = filtered_memory_map;
+        desc < memory_map_end;
+@@ -481,7 +483,7 @@ filter_memory_map (grub_efi_memory_descriptor_t *memory_map,
+     {
+       if (desc->type == GRUB_EFI_CONVENTIONAL_MEMORY
+ #if 1
+-	  && desc->physical_start <= GRUB_EFI_MAX_ALLOCATION_ADDRESS
++	  && (no_limit || desc->physical_start <= GRUB_EFI_MAX_ALLOCATION_ADDRESS)
+ #endif
+ 	  && desc->physical_start + PAGES_TO_BYTES (desc->num_pages) > 0x100000
+ 	  && desc->num_pages != 0)
+@@ -497,12 +499,13 @@ filter_memory_map (grub_efi_memory_descriptor_t *memory_map,
+ 	    }
+ 
+ #if 1
+-	  if (BYTES_TO_PAGES (filtered_desc->physical_start)
+-	      + filtered_desc->num_pages
+-	      > BYTES_TO_PAGES_DOWN (GRUB_EFI_MAX_ALLOCATION_ADDRESS))
+-	    filtered_desc->num_pages
+-	      = (BYTES_TO_PAGES_DOWN (GRUB_EFI_MAX_ALLOCATION_ADDRESS)
+-		 - BYTES_TO_PAGES (filtered_desc->physical_start));
++	  if (!no_limit)
++	    if (BYTES_TO_PAGES (filtered_desc->physical_start)
++		+ filtered_desc->num_pages
++		> BYTES_TO_PAGES_DOWN (GRUB_EFI_MAX_ALLOCATION_ADDRESS))
++	      filtered_desc->num_pages
++		= (BYTES_TO_PAGES_DOWN (GRUB_EFI_MAX_ALLOCATION_ADDRESS)
++		   - BYTES_TO_PAGES (filtered_desc->physical_start));
+ #endif
+ 
+ 	  if (filtered_desc->num_pages == 0)
+@@ -729,7 +732,8 @@ grub_efi_mm_add_regions (grub_size_t required_bytes, unsigned int flags)
+   filtered_memory_map = memory_map_end;
+ 
+   filtered_memory_map_end = filter_memory_map (memory_map, filtered_memory_map,
+-					       desc_size, memory_map_end);
++					       desc_size, memory_map_end,
++					       flags);
+ 
+   /* Sort the filtered descriptors, so that GRUB can allocate pages
+      from smaller regions.  */
+diff --git a/grub-core/kern/mm.c b/grub-core/kern/mm.c
+index 819bc5126..49d4b5284 100644
+--- a/grub-core/kern/mm.c
++++ b/grub-core/kern/mm.c
+@@ -536,14 +536,35 @@ grub_memalign (grub_size_t align, grub_size_t size)
+           goto again;
+         }
+ 
+-      /* fallthrough */
+-
+     case 2:
+       /* Invalidate disk caches.  */
+       grub_disk_cache_invalidate_all ();
+       count++;
+       goto again;
+ 
++
++#if defined (GRUB_MACHINE_EFI) && defined (__x86_64__)
++    case 3:
++      /* Request additional pages, anything at all, but this time
++         without the GRUB_EFI_MAX_ALLOCATION_ADDRESS limit.
++         This is a risky approach because some cannot DMA above 2GB,
++         but give it try and hope for the best.
++      */
++      count++;
++
++      if (grub_mm_add_region_fn != NULL)
++        {
++          /*
++           * Try again even if this fails, in case it was able to partially
++           * satisfy the request
++           */
++          grub_mm_add_region_fn (grow, GRUB_MM_ADD_REGION_NO_LIMIT);
++          goto again;
++        }
++#endif
++
++      /* fallthrough */
++
+     default:
+       break;
+     }
+diff --git a/include/grub/mm.h b/include/grub/mm.h
+index 8ee1fc717..d3bd3c057 100644
+--- a/include/grub/mm.h
++++ b/include/grub/mm.h
+@@ -32,6 +32,7 @@
+ 
+ #define GRUB_MM_ADD_REGION_NONE        0
+ #define GRUB_MM_ADD_REGION_CONSECUTIVE (1 << 0)
++#define GRUB_MM_ADD_REGION_NO_LIMIT (1 << 1)
+ 
+ /*
+  * Function used to request memory regions of `grub_size_t` bytes. The second

diff --git a/grub.patches b/grub.patches
index 6a187e5..98cf868 100644
--- a/grub.patches
+++ b/grub.patches
@@ -424,7 +424,6 @@ Patch0424: 0424-normal-main-Unregister-commands-on-module-unload.patch
 Patch0425: 0425-tests-lib-functional_test-Unregister-commands-on-mod.patch
 Patch0426: 0426-commands-usbtest-Use-correct-string-length-field.patch
 Patch0427: 0427-commands-usbtest-Ensure-string-length-is-sufficient-.patch
-Patch0428: 0428-verifiers-Allocate-EFI-pages-instead-of-grub_malloc-.patch
 Patch0429: 0429-term-serial.c-default-efi0-as-serial-port-if-present.patch
 Patch0430: 0430-commands-tpm.c-include-PCR-check-enable-disable-func.patch
 Patch0431: 0431-commands-efi-tpm.c-check-if-PCR-is-enable-before-TPM.patch
@@ -442,3 +441,4 @@ Patch0442: 0442-ieee1275-ofpath-enable-NVMeoF-logical-device-transla.patch
 Patch0443: 0443-ieee1275-support-added-for-multiple-nvme-bootpaths.patch
 Patch0444: 0444-ieee1275-add-support-for-NVMeoFC.patch
 Patch0445: 0445-grub-get-kernel-settings-Treate-kernel-uki-dtbloader.patch
+Patch0446: 0446-mm-try-allocating-regions-above-defined-limit-as-las.patch
\ No newline at end of file

diff --git a/grub2.spec b/grub2.spec
index 2c48797..176dfb9 100644
--- a/grub2.spec
+++ b/grub2.spec
@@ -17,7 +17,7 @@
 Name:		grub2
 Epoch:		1
 Version:	2.12
-Release:	68%{?dist}
+Release:	69%{?dist}
 Summary:	Bootloader with support for Linux, Multiboot and more
 License:	GPL-3.0-or-later
 URL:		http://www.gnu.org/software/grub/
@@ -625,6 +625,16 @@ fi
 %endif
 
 %changelog
+* Tue Jul 07 2026 Leo Sandoval <lsandova@redhat.com> - 2.12-69
+- mm: try allocating regions above defined limit as last resource
+- Revert 'verifiers: Allocate EFI pages instead of grub_malloc for verified buffer'
+- Resolves: #2263643
+- Related: #2427945
+- Related: #2422881
+- Related: #2453022
+- Related: #2451630
+- Related: #2450672
+
 * Wed Jul 1 2026 Hans de Goede <johannes.goede@oss.qualcomm.com> - 2.12-68
 - Fix default kernel not getting updated when using kernel-uki-dtbloader
 - Resolves: #2463620

                 reply	other threads:[~2026-07-08 17:01 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=178353010681.1.7825171472897023635.rpms-grub2-c30c865bf1b5@fedoraproject.org \
    --to=lsandova@redhat.com \
    --cc=git-commits@fedoraproject.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