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 0C9E6C36002 for ; Wed, 9 Apr 2025 14:28:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 03D2F280087; Wed, 9 Apr 2025 10:28:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F2E09280086; Wed, 9 Apr 2025 10:28:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF662280087; Wed, 9 Apr 2025 10:28:17 -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 C148B280086 for ; Wed, 9 Apr 2025 10:28:17 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 06C8AC022D for ; Wed, 9 Apr 2025 14:28:19 +0000 (UTC) X-FDA: 83314735518.13.3D23F6E Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) by imf19.hostedemail.com (Postfix) with ESMTP id 4F22D1A0011 for ; Wed, 9 Apr 2025 14:28:17 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PW3Ys4Mq; spf=pass (imf19.hostedemail.com: domain of moatasem9626@gmail.com designates 209.85.219.46 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=1744208897; 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=WmAONWbXYFi8kKqgT+CZO9BzFpauTUKIaOtvoGjnXAOeafWGge3g31Dxv/bFasSndIdJ1A xz0YJqlk74CNrVqpmpPGJIU+20+ACVnj+upqiM5aqtmB8RoJX/a/bzJawUiJBWDUgv9FW8 mO/58omenBgSiDwseVPfo6mkvT1dkv0= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PW3Ys4Mq; spf=pass (imf19.hostedemail.com: domain of moatasem9626@gmail.com designates 209.85.219.46 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=1744208897; a=rsa-sha256; cv=none; b=pv7+ODwlJc823XZkEiIXkQ2RmF0M8OkViFmC+83O1/JjydrvxctroF7/HAMCA/bsd2MGhZ k9pOBHW1gmcgdlS/bf7Djm2YhJQnuMAIla4DBT3d3jRxpAvkoBZFqiCxfswqyY6SgvPhsD sfj5HXE9mrhqw83CMeqrfipKYm5nhtY= Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-6f0cfbe2042so9159916d6.1 for ; Wed, 09 Apr 2025 07:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744208896; x=1744813696; 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=PW3Ys4Mq1b5LjzLIrEa1WK5lvRltpo5hfrmjfnvF3oE+KN0kZM+j+MCqTGUmBoGqIY Gp9PrPYmXsP3TcY7srSPSnzMsNvl8PB8i7mANqYMOYsPPlOIYAedx9XVlR4hHC3VUxtW eoxFS4Zldz54F4wzIRj8/2JkALO4T1kLXZIbKlSlkaEJ34QxisbtUW9PS8e/tOyUlEV6 E51kZX62s6rGQRrQo9uxpoPv+gfHGtlQFAZ4B0PEJ7gZtb247O1XB36C7CqZIhBmIhQw YavYPoKo32RkY/JhrItKThfcm/DPGQZCTtY0JHxC5Qqdrmyv0wuSaLZDGzY/NNVTer2h 1rPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744208896; x=1744813696; 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=ekkF7MftaCMRUqkrUU5ljDJyLDy9xN1dqg3mvH/WBYRIGGb2HuEl2j1iHyBqBjmj7w /bx1hlBxrSQLles/M/UBzhtm6E7/CCMIVf5P9A7OIEZDpDAEOvkg+6B64iZxwH34KKEf 0mMLMgo/05wyxMRYUXK9SVUyVCvh8xVXVfJK82PVVzsOtecD05cow10XA2Z+cTEk/DnA mtzy3uNXelAbTaKhDDvA/kNf/c38cGHP3WMXB4j5s0hjzW/ubXlXcS8ZPVSEaokdbE8E hUhcJW75uE7cpWwckWjU3MTe8xDkzygg1aMTIpGkhZqxbLQiSCJbjLmfOeGraYWzpynN 4Osw== X-Gm-Message-State: AOJu0YwLKbn4mI4Ntu+tL7psSEGtQDaL/A5EI4XuJlbPFw3Lqub/qk3P 86bm5mOSSi6AOIbi9bP2p/B0UxRu6Rb+r6EbSN5So9PtId2vNs1ANeG+pxnUfh9xshNA9Iu6NDG fmBCbA2drfNORX30LbdwieSm8/KaCE1Aa X-Gm-Gg: ASbGncsvArzWhkIil0FG4Jb7kmSJClYi+BS8RyvfuHTju+9k/d6ubkmBLhx/vOMVrMH M7WVTlPE+TLZxu+BwaVxKoshQIuXAqH1wk1Bjpd0tn0UICsb/O42Xewan8/AgAgMRJTRoZlgTKC uzXPpukKec0vuIWRIlozCqBPRwtQG3QUMyuZA= X-Google-Smtp-Source: AGHT+IHJezkAM3OZoS5g1BbyLulTp4lfaNNn7VvJqAU05PIlcSQJ0sMpkY/YdHXeZAXnyy7zpwxrkUFvADgst/UeAjA= X-Received: by 2002:ad4:5d6f:0:b0:6e4:4adb:8c29 with SMTP id 6a1803df08f44-6f0d2511286mr120354676d6.12.1744208896296; Wed, 09 Apr 2025 07:28:16 -0700 (PDT) MIME-Version: 1.0 From: moatasem zaaroura Date: Wed, 9 Apr 2025 17:28:00 +0300 X-Gm-Features: ATxdqUGZ6sZiXp_ZVgsRZnx34dLm2RvwAoOJFlySOog790vIAnrhrQW9MaA4g_4 Message-ID: Subject: Request for Feedback on Releasing Reserved Memory Back to the Buddy Allocator To: linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4F22D1A0011 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 5ghbboohtq3nygg93y33dz38cpb5yun3 X-HE-Tag: 1744208897-120638 X-HE-Meta: U2FsdGVkX19rbgrRG7dqzgP2Ax8BjLYLsDjDjJxceWaOhxB7Udb7EkfD/5IM9PnI4woO7zASZpqL6llcqAOkoI/OrlQ+7XguhORHuCtmPK2uv+eAca6jvQJD7Y9M6PSPv2TpAfZEGMwXMQClhhy4JVDHFKq1qcayhsVmEQBWlaaDz7dfB+7mMY0MOhjQRqhwnXU+yj0uI6eUxCvY08l/l19CgqTNiVvC1BbmI+J+sCaHZoBh6tm+IUU/SqyJ19ltJPb9/BW4u/UZXrNwh4hriPWlCSlFyCl9A61CWumup4ih/9cm+pd5i4McWl3O9ZwVkSMLiziJMYA+jjwxPVhLLqWevRxg0wX4aoHnTafemq/nxj8J7KOJoD5yVFuqnY8LtljXQ6wQpTCVgkAqBXp0xO6DoSV/F51gGrW8w0Iknu2kJjxZAgsyYWbB+fjn3mg+OXuZcTWitTvCHHoIEPbcQSvp00vlUh5DO+3Z4SsiHXTWnhrD8y2SmChsKfb2ksMeMHpmOMiuXc+6mAAqngOnRXTcJ7m1Cpa/6lIOaarlqrvwjXqg2t9YI+dBfyYg57ESDOxHlvv0FfUDFcj2kiT/3HaoatcQ59tm9uMHFxanbMpNL6nzsjXjvcE9PtPT1cNx3K95n10kHvVS4orEpdE7lsr2riYduQjI/cU/sxVwvemONazP4SfvzuyLsF7YZB8bXIFByXSXYrS8PSr4Yf2UdkxFNtYKvqfw+t+lAh75l2yfPFswUict7OlhepnzWa72A0f8T9Umbh7SC+leJkm63kPECu7siS1iZakFhOI0j0F47W3B6cqj3XbgSaxvx3fUKycGgU2Kat8SuOeVIErTBwBRFvvypcSctiFAHcl1kO8B9jT22G9hUGexdlGH7VuT0lEBZh3sKBZWeyP3+KVrc0fdp8KGxw1QxKTNdzA+8LzA2HsEyHotr6RMTYofoj2m9V2Kvt6IfORS6gH94SG qtSaJB38 GMFp4Y6jclniDbObGaTgwidQ0FlPn4p0+30nhhrY9KhdhbyaRkHBuL2J/7Qsr8Hnwfb7tNCNad0KChSKcdqnhzjdk4elDMKRIinFUixuRi5evXC1u9fAQdFkMBTTdMfZDDjKJgATvayxNHE5sM+H5htj/Eu13JxzzGsuEQADTE5I8K09NcS6RNcDIuENa88JO48LEQiHXuCFJHc+ctp7VbeXSW1OHgccHv7QDbMCu47L+BpOEwrtNsTIGDPB8+AcIj10yIzAIDv5LYbfJ50ZuqQ/cItJ3vaVYHAdpowhBwxK7IJjNZgJuSjVEO/Fvn7uvRM389pZK1LJxi5mVYxH8WJXEgg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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