From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E22C0C3601E for ; Thu, 10 Apr 2025 10:19:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5CFD52800B9; Thu, 10 Apr 2025 06:19:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 57E7E2800B5; Thu, 10 Apr 2025 06:19:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 46BFA2800B9; Thu, 10 Apr 2025 06:19:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 28B512800B5 for ; Thu, 10 Apr 2025 06:19:18 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id ABE3C1608A6 for ; Thu, 10 Apr 2025 10:19:19 +0000 (UTC) X-FDA: 83317736838.26.48D86A6 Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) by imf30.hostedemail.com (Postfix) with ESMTP id 0F0DE80012 for ; Thu, 10 Apr 2025 10:19:17 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=BE1oKlZ2; spf=pass (imf30.hostedemail.com: domain of moatasem9626@gmail.com designates 209.85.219.43 as permitted sender) smtp.mailfrom=moatasem9626@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744280358; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=Y5PL+mdu3Ixrvo2IlHyQIckc2kUzUrG+XY2ZRBmMzfA=; b=X6yg1H/GirmiUGrIqr0zDAJo4mfzCilTlaocV4P1zJ+XBoCs622gfgAXHoM/FUfYEZDnxy pBtVcNmWND5GYf2RokDAck5tR/HIRSRANz+UukWbm//SxUIPbN9b0GgI+RNqfF2jlaIr+/ VD4nwRXrSZcewEjOOX6AJYe4on51jC4= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=BE1oKlZ2; spf=pass (imf30.hostedemail.com: domain of moatasem9626@gmail.com designates 209.85.219.43 as permitted sender) smtp.mailfrom=moatasem9626@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744280358; a=rsa-sha256; cv=none; b=YL+HIgrMoKSof+M3w5/jSufXKEXetrcMVa0z+1Vwebmw+VWHWAHQ1WVisDt51WE/xbhMrT QE39STqYWyO1GrkawPw9a6K64zFax2IK/+FY2nLXaYXkAwpjzBmh44cXRNysIJuBLYGUSG PXElVlL/W6BZhdkYLxyat+2AFughhes= Received: by mail-qv1-f43.google.com with SMTP id 6a1803df08f44-6e900a7ce55so9090696d6.3 for ; Thu, 10 Apr 2025 03:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744280357; x=1744885157; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Y5PL+mdu3Ixrvo2IlHyQIckc2kUzUrG+XY2ZRBmMzfA=; b=BE1oKlZ2lXK9nsyzI8Qy62tsjcIyf8qEm4RcFMvMSfRYZZ0ma1rBYP+Z31oU/OaAsx ymbnb3RiZ5huE27a4ZSMrIJkIQulzEjad0rbf2tWPSg6UjDxgxOtbX9bKR6o0AykMaYP KRlSbKM50KD9O44UncFfRZmRjdXcka3RSSw1/YgHTfvN4HE9vW2N797vV7xCNX0jnUwK GQYZxc0fwbF1ctdzMcsJHmydF9vCbZaYJTY8jLvtvF+IrBknOpBmBn7E3xWepQcvcywi fULXJbCRNBgkmIGxANYs9etgmoiSXd7RdDa3+/AnpuXFcEQ3OXFRQpYsi/5wE6DbbUg9 OkYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744280357; x=1744885157; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Y5PL+mdu3Ixrvo2IlHyQIckc2kUzUrG+XY2ZRBmMzfA=; b=aGiRi6PDjM5C5x6oxQUK6g+rg52MpjpoSWeLS8tlTm1C/tBPfckb9XkeVLZQOMSiAH 828O69FQTCUpx3+NyXB2oafSD8nVAu5uS71kF7+/9HcajFRmGhxHTboL43n76x9N/YvT jv9JmeT7x0LooVUTYDKDEtYeGIbSW0T24MTV1lZ/M8x1ma1krkoHwIvXcQn5etbO1/er beyfi4OOP2MPczZECEQFioUAx3cWleUUVy0/azbGQ+MxE9kAuwT3xF+je+VqjqG389x9 l9stpHJs/ae/5QEUfceNEYqc5/wMO6iFxGyy3lEqR8KY64rfRbJk45ZbX1H1UveIxatv mAgQ== X-Gm-Message-State: AOJu0YwERghda3Rqv2QnhilgsMpLg77WYiD6Fn65SvqGdrD0R4tfKbuD /Zq/FvtwLGo1KCbiD536QKgj8JATVQTu4pFLXB7GaxG6KUf0H3X8+De09mA6/LyNUycfawwknnc 1SSw4Dl++63QHpWWs0VOAzKF38Btw2imv X-Gm-Gg: ASbGncsgCHSNv6cyrfAd6uemOB5NdyE3S2fpxjcnbbNhBOlOEdxAxFnMIm52/QiXNwU FJ9+r04RhEbDLjfvmpfPrz2iVxs3MM9c5KPut4u7GOnS3rY6VWUu9VGT51lYHUflA7J3w+9BChl PHTFxjINVdgOLQhV/UN2bYVQUk X-Google-Smtp-Source: AGHT+IGI6aM+JeHo/LBF9PwqdoHHulV8pDyb4rCybmNwsLghBOmcTWeCODId1hLid7Hn85yGsmKwvIusq9WUxsV/q3A= X-Received: by 2002:ad4:576d:0:b0:6e8:fa33:2965 with SMTP id 6a1803df08f44-6f0e5a29b58mr28332886d6.14.1744280356917; Thu, 10 Apr 2025 03:19:16 -0700 (PDT) MIME-Version: 1.0 From: moatasem zaaroura Date: Thu, 10 Apr 2025 13:19:00 +0300 X-Gm-Features: ATxdqUHfYBwzTv15I07HflsjdQduq2SSqCZ0dlmyYFXvJ5VaIYSnuVdr5c5yuvI Message-ID: Subject: Free Reserved Memory and return to the Buddy Allocator To: linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 0F0DE80012 X-Stat-Signature: j7ghyspi1rm8w19jfz85hqjw8oe97dna X-HE-Tag: 1744280357-596340 X-HE-Meta: U2FsdGVkX1/N59UzY71ffOUp0bl9cub8FjXX3DsHRRSpa51eFR+Q4/HmyEXMEdoJdd1FU8fWxloox5fgAwP/kXrZYWK5H99hVcUW/2jACjOUmJ9OmcUlbNsA/sfdasemh5qTdh7FH5ivvl+lpIxrMXwhrZcPiGfINlioNpG3u4iojF4NqbKayJQ8f8dS8ZlcflgUPVXeBcF5kAWojwUtwl+tteSbbuplha7PK1wrEW5He2oXrGkm0yIcn5rBUfNIgX3xRy6L070UFYnYZCiO4yiFoYwFuoGaMXEbTKQPtDFy/L04aWE17EV7/SiWQB62Yh9KnaOlN2efLu0dkUxhnrb5FyAL8g9SXHGD37I5iNZ6p9o7qc24/JUxNgHGcSkUFhxNsw8eBPbMaFDira0r5W2KhV7YW8R5lNxFDBy91EwKIbw9/TD+eUuBLpBv+Eji+M1gjHsLxlVq1ktE6KhBdowrUtDR/a/MbmvA3o4pzysH2cUrRDMn3Zj7z4eNFoCHSQsI4TyY5LyPRTiEjbKEisSKqkwhxW5ca/61v1GSm5Rca55NeJBvenHJ4ZmpwxFcRxt0KZDQyE2N4IZhzveGiWG78FlmjZOi1HMczdiHwFHxGkniHwTGr0G+mhXf/jxrNHH+NI3Lu7cpW3swRMJD6FG+nD6rXzgSj8wG/ib0y/w2vYZbFHgqs9lVVIMlXGFKMHNVKPdOHL1opNMfzz+sDLgdBstVc9zLaz1ivim9w8IUUY9dfhOK7dL78Bk9XejbLbNeqxnDnf0dzk5cTr1mhuctuqU35jjsrAmMHHxOfp1FSPkITd3j0F+6GgYC1qnTBt77EGBr6stoO+kyXeeWF5gAXSzAiyj9IpXOOg10wdpjBszXs36hEf7Bvpi9COGWqXZu3/hF6TUwmDWaYgU+JoRu0TkeZXV1MJsNWFmyM0SpzWeJ1/CIDTSbtpC7jWxIkv5V2fyyuzam7Jj0Qjx I2OGbNmp h0MI54dCnL9OZl09dpWcFNAEkbuBJ4miCA6k/9wMUMuvr2SAPzYUwbqiEOWzI3visOhr2exWESa4BNQahy+ApkqJmB2zqXhhLsWpsCmEcNTwNUHg3NPYHlmrx4UYVoaWKL6JDZ2kTOPiVkAVAcpAwpUaJcCGALVStqe0NfLGG9T7Z3YCallko6MX9DKfa408NKBCHvP2olfMycUx0USu4VvgslIpAtGOzIGR0+BqmicU2OygOIjrjtHhbkh5yiDqshgXVgfUIJUY+T/381xAVi83selo7h61IYXpb7p7XDsJJ56DfldUJtMQkqQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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=E2=80=99ve taken, including any concerns, possible pitfal= ls, or alternative recommendations. =3D=3D Problem Context =3D=3D 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. =3D=3D My Solution =3D=3D 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. =3D=3D Freeing Logic =3D=3D In the release function: - I validate that the physical address (cache_addr) is page-aligned. - I calculate the PFN using: pfn =3D PFN_DOWN(cache_addr); - Then I loop over the pages: size_t i; struct page *page; unsigned long pfn; unsigned long number_of_pages =3D cache_size >> PAGE_SHIFT; if (cache_addr & (PAGE_SIZE - 1)) { pr_err("Physical address is not page-aligned\n"); return; } pfn =3D PFN_DOWN(cache_addr); for (i =3D 0; i < number_of_pages; i++) { page =3D pfn_to_page(pfn); // Ensure the page is not part of the reserved pages if (PageReserved(page)) free_reserved_page(page); pfn +=3D 1; } - I verified that the memory is successfully returned to the buddy allocator by observing the increased number of free pages at /proc/buddyinfo. =3D=3D What I'm Asking For =3D=3D - 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 =E2=80=93 Mobileye