Request for Feedback on Releasing Reserved Memory Back to the Buddy Allocator

[moatasem zaaroura <moatasem9626@gmail.com>]

Dear Linux MM Community,

I am working on a system that requires reserving a known physical
memory region during the early boot phase and later releasing it back
to the kernel for general use. I would highly appreciate your feedback
on the approach I’ve taken, including any concerns, possible pitfalls,
or alternative recommendations.

== Problem Context ==

In my use case, the boot manager must copy data from flash to a known
DRAM location while the Linux kernel is still booting. This data is
then used in user space. After the user-space component finishes using
the data, I want to release this memory back to the system so it can
be utilized by the buddy allocator.

== My Solution ==

1. I reserved the memory region using a "reserved-memory" node in the
device tree with a fixed physical address and size.

2. This address is shared with the boot manager, which copies the
required data there before the kernel accesses it.

3. After the data is no longer needed (in user space), I expose a
sysfs interface to manually trigger the release of this reserved
memory back to the kernel.

== Freeing Logic ==

In the release function:
- I validate that the physical address (cache_addr) is page-aligned.
- I calculate the PFN using: pfn = PFN_DOWN(cache_addr);
- Then I loop over the pages:

        size_t i;
        struct page *page;
        unsigned long pfn;
        unsigned long number_of_pages = cache_size >> PAGE_SHIFT;

        if (cache_addr & (PAGE_SIZE - 1)) {
            pr_err("Physical address is not page-aligned\n");
            return;
        }

        pfn = PFN_DOWN(cache_addr);
        for (i = 0; i < number_of_pages; i++) {
            page = pfn_to_page(pfn);

            // Ensure the page is not part of the reserved pages
            if (PageReserved(page))
                free_reserved_page(page);
            pfn += 1;
        }

- I verified that the memory is successfully returned to the buddy
allocator by observing the increased number of free pages at
/proc/buddyinfo.

== What I'm Asking For ==

- Is this approach correct and safe under the current kernel memory
management design?
- Are there any problems I may have missed?
- Is there a better or more canonical way to achieve this?
- If the approach is sound, I believe this pattern may be useful for
others, especially in embedded systems. Would it make sense to
document or upstream a helper for this purpose?

I would be very grateful for your input and guidance.

Best regards,
Moatasem Zaaroura
OS Team – Mobileye