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 BBBF1C4332F for ; Wed, 4 Jan 2023 07:43:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C6B868E0002; Wed, 4 Jan 2023 02:43:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C1BFD8E0001; Wed, 4 Jan 2023 02:43:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B13B78E0002; Wed, 4 Jan 2023 02:43:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id A1C288E0001 for ; Wed, 4 Jan 2023 02:43:35 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 68F8D80408 for ; Wed, 4 Jan 2023 07:43:35 +0000 (UTC) X-FDA: 80316326790.18.060E51B Received: from a27-20.smtp-out.us-west-2.amazonses.com (a27-20.smtp-out.us-west-2.amazonses.com [54.240.27.20]) by imf09.hostedemail.com (Postfix) with ESMTP id C4FCD14000D for ; Wed, 4 Jan 2023 07:43:33 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=aaront.org header.s=ude52klaz7ukvnrchdbsicqdl2lnui6h header.b=QOWpEF16; dkim=pass header.d=amazonses.com header.s=gdwg2y3kokkkj5a55z2ilkup5wp5hhxx header.b=Zpn6P8cO; spf=pass (imf09.hostedemail.com: domain of 010101857bbc3a41-173240b3-9064-42ef-93f3-482081126ec2-000000@ses-us-west-2.bounces.aaront.org designates 54.240.27.20 as permitted sender) smtp.mailfrom=010101857bbc3a41-173240b3-9064-42ef-93f3-482081126ec2-000000@ses-us-west-2.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=1672818214; 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:references:dkim-signature; bh=d/kS2qV6jUTi2z7KiqaKiSozpqh0oc2+tu1KAR2pOxA=; b=3MKCYkG1tE2iSekjpD+rzF1piWEMIpgFQfz/QaKVHFeHin4zf8Wr6h0BbkToNsh6pydEC8 /o+Cx7ln6v+Xb5iNWjhH27n5sOmWzHue9c/cB2p1yoDbwuon7U4lVuA21IY+fCD4hiR20j 6QV7bGbuByRuxaIyowUI/UGXvAWI0vc= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=aaront.org header.s=ude52klaz7ukvnrchdbsicqdl2lnui6h header.b=QOWpEF16; dkim=pass header.d=amazonses.com header.s=gdwg2y3kokkkj5a55z2ilkup5wp5hhxx header.b=Zpn6P8cO; spf=pass (imf09.hostedemail.com: domain of 010101857bbc3a41-173240b3-9064-42ef-93f3-482081126ec2-000000@ses-us-west-2.bounces.aaront.org designates 54.240.27.20 as permitted sender) smtp.mailfrom=010101857bbc3a41-173240b3-9064-42ef-93f3-482081126ec2-000000@ses-us-west-2.bounces.aaront.org; dmarc=pass (policy=quarantine) header.from=aaront.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672818214; a=rsa-sha256; cv=none; b=KGkpgIjrmnDIrnkHr68gMVDZ0mTFN3Mf10JocED0m0skBfv1o01mI7pg+Lc2Y/gZ/WGFS8 dnibWtDAwQRq6Uj12n12q7jKYLOk7BeXKKQaO3HgbHX8ipI6XfX1VVsdDg+heiCEWqPGFG D+hp336f0V4ya1EA72NtBoXe49sY7m8= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ude52klaz7ukvnrchdbsicqdl2lnui6h; d=aaront.org; t=1672818212; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Transfer-Encoding; bh=Wj7klY86vgtWMpFXPcL7VhH5cXg34dvEywUtgtkdsuI=; b=QOWpEF16QFYnFtfERkKmMgaJ/pHcACnd9XRFlYJtdjcAS31G2mCxLvws0Zt6yC25 yk2lE4dJp7fB4lxngj58j0n/gmqSG9kZKI8oGh3pzzJkTGrLPeRVc7oSW1pJuwnGbUS RANqHANUTWtmagTq7O2pb50MHmoKj2wl/mgsVaWk= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=gdwg2y3kokkkj5a55z2ilkup5wp5hhxx; d=amazonses.com; t=1672818212; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Transfer-Encoding:Feedback-ID; bh=Wj7klY86vgtWMpFXPcL7VhH5cXg34dvEywUtgtkdsuI=; b=Zpn6P8cOMw6L+wGAWZentm/sIjv+oHTVrNbQWl1qkIICnowu8Un8q/aFe2fzpB2N jbxUMu4uCqkynPLVHUqpx/6k+f6o34vJ73MdC+3+5M1YucUHMamM3KPFc+H3ShD33Md dBCCRPhkC3XxNs1U9hLmQ00rfP7whFKZRaFv/iUg= From: Aaron Thompson To: linux-mm@kvack.org, Mike Rapoport Cc: "H. Peter Anvin" , Alexander Potapenko , Andrew Morton , Andy Shevchenko , Ard Biesheuvel , Borislav Petkov , Darren Hart , Dave Hansen , 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 0/1] Pages not released from memblock to the buddy allocator Date: Wed, 4 Jan 2023 07:43:31 +0000 Message-ID: <010101857bbc3a41-173240b3-9064-42ef-93f3-482081126ec2-000000@us-west-2.amazonses.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Feedback-ID: 1.us-west-2.OwdjDcIoZWY+bZWuVZYzryiuW455iyNkDEZFeL97Dng=:AmazonSES X-SES-Outgoing: 2023.01.04-54.240.27.20 X-Rspamd-Queue-Id: C4FCD14000D X-Stat-Signature: 1t61g1yqzm6hnpb9ok3knefpsbay1r61 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1672818213-59562 X-HE-Meta: U2FsdGVkX1/vWNcEP01Qsqi4tJjeaBzzXlepHYD+rq66+Y6bp7XRLtQpyHir7AhrtXjx0rf92sFSrgdJ6NcCyTojaAXfv90+cVT8OF5oslJzBKXvynneaHYVnc8zOcR0e/pvFm1HwxcOU6bVr8GmKywypMFrHSvtwMk99wX64COhUXhtabEQSawm+ZM3twNVGxL1KNI7dSlTeH0SUjHlGAOtPmLPgG8Cb0COB6IyXpf9FEwdgiUn1HdIcUNDHnwoEu+Pb1IPSujb5HPAT3m4LE/3poaR7oJJQ6LBc4nB2FlFmKMMBUnUOXZefQRWE5j2R/3qIZ86l1JG77VKW9nepvdNfD056n/enLFEWL/oM/d43z4wTLt92OF28ZCA8R7snvQ1sAVeJXPCzqU1f4MwfGwhMPoypc5MFytJ+TEwB4m95o9HKrcPy4/8bdMyJ1C0jHnpSEjyXPM/gYO9FOOYXbx0vfQyPoU5imW6FY+GxRMKZ3XAvK0sxWl2hlOd3UmEd1qQu0PVRons9RV2wXtv4W9Lgx+L5HWn2+6rl8WZjijO23pFuJ1papl3nYj/5ViRkc7obeiiTN90SCP306cgY/Mayg2Epj+xKHRuozO48JfgZGeC1MouFpD7t4ceU77cAVINHFT7FvLLQb6kPrEYUYUVGYdf7v+oLGeU3p4rjyLUMWM5V9AQqtjmERcx7toMPgEiCFdSG2YQJa8cH5AV7M5qTtOSHnq6MCJyp10EIGcmI1j/rHJEe51o87Q1iycZ/JMVMrSRj8zNV56eLBf9vd2wpvekc5YF1EhqUphTdigsjQ0MKDocqQ4Z5RsrET/sewSbj2gTmsMlCvE7T4CS6u+RYwTZ+vf/lmmg5tBOLZZI0PRa+nsc4I82kaH8yZY/AEL4Awz1+Ft01npCE9gAfZpofW19YlXs3VOr9Wvza2KBTTj/1LrISG9YNz8t64xEqhifwjepfFRsFp+R13M Q+wan6ay 9lOUp4X4MtsYAkCCJatWzdQkmjoaHugJD0f968doIjNYtfpfjL8p3t4eQLyjZb61riOrVL4cQH9KZDwA6eE9tagjgtjCj9aGKpkAxT5abGLOFbTFj1lrertmm/cmUtmP74Ee8vW7hPGeFSV2ZrQgWW6Z1K4h5X8nkndUWVyr3rg/RIwapo0fRdOeBh1vJ8W9v3ua4ZmD9PuNCgWQLyi6/0IFPEQfBhPqqqCZZmfY58kzEezeFer2/YRn9PDp5YmhuVnShqPFZ1Zq7NZps7PrX1OAvOWn/1AmpXlqceI5clngOn2U= 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: 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 | 2 +- tools/testing/memblock/internal.h | 4 ++++ 2 files changed, 5 insertions(+), 1 deletion(-) -- 2.30.2