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 17225C3DA7D for ; Thu, 5 Jan 2023 04:17:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7B7C78E0002; Wed, 4 Jan 2023 23:17:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 740658E0001; Wed, 4 Jan 2023 23:17:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BB768E0002; Wed, 4 Jan 2023 23:17:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 499748E0001 for ; Wed, 4 Jan 2023 23:17:25 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 21F951C606F for ; Thu, 5 Jan 2023 04:17:25 +0000 (UTC) X-FDA: 80319436050.18.91A0D29 Received: from a48-122.smtp-out.amazonses.com (a48-122.smtp-out.amazonses.com [54.240.48.122]) by imf09.hostedemail.com (Postfix) with ESMTP id 542A5140009 for ; Thu, 5 Jan 2023 04:17:23 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=aaront.org header.s=zp2ap7btoiiow65hultmctjebh3tse7g header.b=DvN1oZol; dkim=pass header.d=amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b="D/diO4iD"; spf=pass (imf09.hostedemail.com: domain of 010001858025d78c-8d8b175b-8d52-4bc1-9c93-311868a527a2-000000@ses-us-east-1.bounces.aaront.org designates 54.240.48.122 as permitted sender) smtp.mailfrom=010001858025d78c-8d8b175b-8d52-4bc1-9c93-311868a527a2-000000@ses-us-east-1.bounces.aaront.org; dmarc=pass (policy=quarantine) header.from=aaront.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672892243; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=d6FDebMWjBtfyK0g460tmOAYf0uEUarjYi7SLHlQCJs=; b=oZsNGEISPO3pdVVJk64ZWmfXCJRgJ84KWUgow874lSpMpdJWB2UuL6LRW/TzQONHjpqcOo 6YzOOBqwkE/sGtQlqFionNk0CIc+YlVbodOjSebms6TBW2eLzSIUJZIAY8y2akXHcAkgCQ wGsEphiv6Z/3uSbk+g/8LjyxcAt3yyo= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=aaront.org header.s=zp2ap7btoiiow65hultmctjebh3tse7g header.b=DvN1oZol; dkim=pass header.d=amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b="D/diO4iD"; spf=pass (imf09.hostedemail.com: domain of 010001858025d78c-8d8b175b-8d52-4bc1-9c93-311868a527a2-000000@ses-us-east-1.bounces.aaront.org designates 54.240.48.122 as permitted sender) smtp.mailfrom=010001858025d78c-8d8b175b-8d52-4bc1-9c93-311868a527a2-000000@ses-us-east-1.bounces.aaront.org; dmarc=pass (policy=quarantine) header.from=aaront.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672892243; a=rsa-sha256; cv=none; b=H1Xr3zykND8JC5IyKqUozJMthUunydmzaQ/QTcW7e/9BxnGtOVoyPlVp1grIiNyL4HzIVI LTjbo0/EJXAfGj5h4xVxGm62mpvHP4xzePcYsvMJVkxV5oDm1XWWSsVqZ+Qk8BiGlLtSUN YLucxBeYIupXDbVFr2tdhsjfx3AXPHU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=zp2ap7btoiiow65hultmctjebh3tse7g; d=aaront.org; t=1672892242; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding; bh=ztItl4b4AGozQuiVdDoNJP/Y4TYiTtgmkp/xzra7dzQ=; b=DvN1oZolBWw/4T0pNVS0kgp8xvmvDy2CfRShaw1vQtfNG14fvyvY+YwgEzTxCMU/ 0rbLNjEB+6mBjZ+IOvmtAb/B/Qy8FKdTC0xiT9fn/GUuT8jRgZ6DtyaB3DgW3gMfh2Z pXo5ws8KHN2kujyDbv71jfnFAkBKjI1quLrHaAHM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1672892242; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Feedback-ID; bh=ztItl4b4AGozQuiVdDoNJP/Y4TYiTtgmkp/xzra7dzQ=; b=D/diO4iDIPT1XpcgoNIPBAf8R21vDqjPlwgDkmg7QIKg09yzhw1c56u/Tj2/nOrS ICHW73K3MbulAuOGRIDNWby52Njmxvc91hQvEe2LIuJCIu/Omvb2GLN4N6tk7JrmY60 AecS0MjImpydVV+CuBxV9JCZ+DHkvZ/knIXIlsuQ= From: Aaron Thompson To: Mike Rapoport , linux-mm@kvack.org Cc: "H. Peter Anvin" , Alexander Potapenko , Andrew Morton , Andy Shevchenko , Ard Biesheuvel , Borislav Petkov , Darren Hart , Dave Hansen , David Rientjes , Dmitry Vyukov , Ingo Molnar , Marco Elver , Thomas Gleixner , kasan-dev@googlegroups.com, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org, x86@kernel.org, Aaron Thompson Subject: [PATCH v2 0/1] Pages not released from memblock to the buddy allocator Date: Thu, 5 Jan 2023 04:17:21 +0000 Message-ID: <010001858025d78c-8d8b175b-8d52-4bc1-9c93-311868a527a2-000000@email.amazonses.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <010101857bbc3a41-173240b3-9064-42ef-93f3-482081126ec2-000000@us-west-2.amazonses.com> References: <010101857bbc3a41-173240b3-9064-42ef-93f3-482081126ec2-000000@us-west-2.amazonses.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Feedback-ID: 1.us-east-1.8/56jQl+KfkRukJqWjlnf+MtEL0x/NchId1fC0q616g=:AmazonSES X-SES-Outgoing: 2023.01.05-54.240.48.122 X-Stat-Signature: z7xzbin6k4b3tot6kma6r7bwiuwtpj5j X-Rspam-User: X-Rspamd-Queue-Id: 542A5140009 X-Rspamd-Server: rspam06 X-HE-Tag: 1672892243-845946 X-HE-Meta: U2FsdGVkX1/dNJEScvMMEhgUW+DF5q3B7Jhvrhbi4M300v0U9nFNFXPQaK34GhV8XCmTHAEgkW7qr7y3QSK4NpssRZDbm0xpB2jYXHCXPPmpAlhOSlcDRtnPNCLvZyoNQj7AC1xTDZlEpeBrYLQkxd8CM2lSZHMvctOo7OVnQKploXyg1rQ3g25Ql4fSfIPJ/nJM2e+G0AZjaJza86GqGflVya2Y6GYP0blwDtuyeEk6UbbsYJ0qjbabgnFzLKGqIxqddy7+LcaruBxqh6AULwiPZ/9XvvDKx8Vg2hvcb4PyuuNXBHlqN4lH470Vry4YMRALszw81nw0gfg4A78ShMRdchvWfCxKIe96H50SCTzqatI5C1E26XhICZDyh63+2eeM1yy+zXEfmI7G/eB/zQYwtNhqgrBUXDdDqehjx/cP4gAU9sX6FHNOkBobAw9VUyMZOVrkxZXQU9MfRK7/DuO6RA8bHSTLYN1Tbkoxukza6TI6fY3HSAGywEbtZjmRwxj30esx/4bVhNvGtGv/mQJqwSQRIGiFWjBzT11RO7OHk2tF3D5uosUdWw/cp4+7xJfynE6lEAwzs220C/stX8rYGEXg3lTMCj2HEcSFVe7HaVYYBOA2MakvJx/A0M8BB4YfHWQwdNuOZx6R9nTVf87h+yRcKQjocdS71gLmJ77kNNnsBz1g6dLl9YVxAMmkLmoN0vFEiwvhdqzlxS8tPezFO3MJddLdGkjq6s3OxJGN3vdiFrB1OY0h/GyG9xtSKDzI+hGixNocNcQatith1jgDr+TbH+Y3ahrRcnQA+2hJGPMjCHn2jUs3gqKXb1CDhPIzJhkM2xxBExFbtNej8ucapIykbTJmuwU14rE4mJ1KsbRCDZl9//mN+S8sdHMke4MCChjW0Bc6tJ8FmZoZ4rDyCn82SCtnxmnmNoy0at6adOWs9ncPmtgIuSb/0rKOyBWeFQ/tQz9gZW7i9dt Z+1YyS8A S/BWnKeVOfeBrifwrUR8UK4JGn49/ZmKzG2DqZlnfSKaTEWvzNECDXoKDcCMv2VWMyF2UW1DROnrLjeFjSdQyEoV9w2Nbah/6qGLdVRssPWc4udvKzqlBLr6ybTwkWVdeoxIQyW+vmKVwuqOoNqv1tyx1X+k0I7W06fDyRD6PWt5C24XN38bWhyIYa8Ao6hb0I8RlBmwQn83+fv3w16klXYU8HHduC8NJ/Tz3guWoCUlfK06G9RqnvFjrnwDquHbvmV7LO5nnGEnB2WP8IWoGlZlEua+jSMthNWdDOmBQ9X65AGCpN7VjU1fnjU+LPVMyICj9l3fJV82Pj9K0pO6sKYftgaxHYiy94zglHp9v5jR951pVZ9qcgRXzBw5+DuPjzgCQmD9FmrY59rU= 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: Changelog: v2: - Add comment in memblock_free_late() (suggested by Mike Rapoport) - Improve commit message, including an explanation of the x86_64 EFI boot issue (suggested by Mike Rapoport and David Rientjes) Hi all, (I've CC'ed the KMSAN and x86 EFI maintainers as an FYI; the only code change I'm proposing is in memblock.) I've run into a case where pages are not released from memblock to the buddy allocator. If deferred struct page init is enabled, and memblock_free_late() is called before page_alloc_init_late() has run, and the pages being freed are in the deferred init range, then the pages are never released. memblock_free_late() calls memblock_free_pages() which only releases the pages if they are not in the deferred range. That is correct for free pages because they will be initialized and released by page_alloc_init_late(), but memblock_free_late() is dealing with reserved pages. If memblock_free_late() doesn't release those pages, they will forever be reserved. All reserved pages were initialized by memblock_free_all(), so I believe the fix is to simply have memblock_free_late() call __free_pages_core() directly instead of memblock_free_pages(). In addition, there was a recent change (3c20650982609 "init: kmsan: call KMSAN initialization routines") that added a call to kmsan_memblock_free_pages() in memblock_free_pages(). It looks to me like it would also be incorrect to make that call in the memblock_free_late() case, because the KMSAN metadata was already initialized for all reserved pages by kmsan_init_shadow(), which runs before memblock_free_all(). Having memblock_free_late() call __free_pages_core() directly also fixes this issue. I encountered this issue when I tried to switch some x86_64 VMs I was running from BIOS boot to EFI boot. The x86 EFI code reserves all EFI boot services ranges via memblock_reserve() (part of setup_arch()), and it frees them later via memblock_free_late() (part of efi_enter_virtual_mode()). The EFI implementation of the VM I was attempting this on, an Amazon EC2 t3.micro instance, maps north of 170 MB in boot services ranges that happen to fall in the deferred init range. I certainly noticed when that much memory went missing on a 1 GB VM. I've tested the patch on EC2 instances, qemu/KVM VMs with OVMF, and some real x86_64 EFI systems, and they all look good to me. However, the physical systems that I have don't actually trigger this issue because they all have more than 4 GB of RAM, so their deferred init range starts above 4 GB (it's always in the highest zone and ZONE_DMA32 ends at 4 GB) while their EFI boot services mappings are below 4 GB. Deferred struct page init can't be enabled on x86_32 so those systems are unaffected. I haven't found any other code paths that would trigger this issue, though I can't promise that there aren't any. I did run with this patch on an arm64 VM as a sanity check, but memblock=debug didn't show any calls to memblock_free_late() so that system was unaffected as well. I am guessing that this change should also go the stable kernels but it may not apply cleanly (__free_pages_core() was __free_pages_boot_core() and memblock_free_pages() was __free_pages_bootmem() when this issue was first introduced). I haven't gone through that process before so please let me know if I can help with that. This is the end result on an EC2 t3.micro instance booting via EFI: v6.2-rc2: # grep -E 'Node|spanned|present|managed' /proc/zoneinfo Node 0, zone DMA spanned 4095 present 3999 managed 3840 Node 0, zone DMA32 spanned 246652 present 245868 managed 178867 v6.2-rc2 + patch: # grep -E 'Node|spanned|present|managed' /proc/zoneinfo Node 0, zone DMA spanned 4095 present 3999 managed 3840 Node 0, zone DMA32 spanned 246652 present 245868 managed 222816 Aaron Thompson (1): mm: Always release pages to the buddy allocator in memblock_free_late(). mm/memblock.c | 8 +++++++- tools/testing/memblock/internal.h | 4 ++++ 2 files changed, 11 insertions(+), 1 deletion(-) -- 2.30.2