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 CAD0AC433F5 for ; Wed, 15 Dec 2021 14:15:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1FC6D6B0080; Wed, 15 Dec 2021 09:10:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1ADA36B0082; Wed, 15 Dec 2021 09:10:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09AE36B0083; Wed, 15 Dec 2021 09:10:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) by kanga.kvack.org (Postfix) with ESMTP id EE91A6B0080 for ; Wed, 15 Dec 2021 09:10:54 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B39B5180E9346 for ; Wed, 15 Dec 2021 14:10:44 +0000 (UTC) X-FDA: 78920214408.18.C9BE417 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf04.hostedemail.com (Postfix) with ESMTP id 2346240014 for ; Wed, 15 Dec 2021 14:10:44 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D961EB81F22; Wed, 15 Dec 2021 14:10:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24F1FC34605; Wed, 15 Dec 2021 14:10:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1639577441; bh=D6a6SsHePSGwundOJdGmlbSnbMh020j3K/1vL86iLMo=; h=Subject:To:Cc:From:Date:In-Reply-To:From; b=Dn9vGrUzXvBVyZMTRFeLxgjreJA9SOjLLj9PM655uDRroOmTyZIKftg0dGZw5QQWQ 368LR+sPqsxRcwsJF13uUz5XqpmMa5df/asJSRRoBLMUqAKFdrohoOG9GAQRzs9qqY enG2QBHj03uF8bExPpV6ykr0NLXmoqRfWebLHSZU= Subject: Patch "arm: extend pfn_valid to take into account freed memory map alignment" has been added to the 5.10-stable tree To: akpm@linux-foundation.org,gregkh@linuxfoundation.org,linux-arm-kernel@lists.infradead.org,linux-mm@kvack.org,linux@armlinux.org.uk,mark-pk.tsai@mediatek.com,rppt@kernel.org,rppt@linux.ibm.com,tony@atomide.com,wangkefeng.wang@huawei.com,yj.chiang@mediatek.com Cc: From: Date: Wed, 15 Dec 2021 15:10:10 +0100 In-Reply-To: <20211213094135.1798-5-mark-pk.tsai@mediatek.com> Message-ID: <163957741020166@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 X-stable: commit X-Patchwork-Hint: ignore X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 2346240014 X-Stat-Signature: oxzd676e393xqnq6ufka1p6w646xcafn Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=Dn9vGrUz; spf=pass (imf04.hostedemail.com: domain of gregkh@linuxfoundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org X-HE-Tag: 1639577444-12304 Content-Transfer-Encoding: quoted-printable 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: This is a note to let you know that I've just added the patch titled arm: extend pfn_valid to take into account freed memory map alignment to the 5.10-stable tree which can be found at: http://www.kernel.org/git/?p=3Dlinux/kernel/git/stable/stable-queue.g= it;a=3Dsummary The filename of the patch is: arm-extend-pfn_valid-to-take-into-account-freed-memory-map-alignment= .patch and it can be found in the queue-5.10 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From foo@baz Wed Dec 15 03:01:20 PM CET 2021 From: Mark-PK Tsai Date: Mon, 13 Dec 2021 17:41:34 +0800 Subject: arm: extend pfn_valid to take into account freed memory map alig= nment To: Cc: , , , , , = , , , , , Message-ID: <20211213094135.1798-5-mark-pk.tsai@mediatek.com> From: Mike Rapoport [ Upstream commit a4d5613c4dc6d413e0733e37db9d116a2a36b9f3 ] When unused memory map is freed the preserved part of the memory map is extended to match pageblock boundaries because lots of core mm functionality relies on homogeneity of the memory map within pageblock boundaries. Since pfn_valid() is used to check whether there is a valid memory map entry for a PFN, make it return true also for PFNs that have memory map entries even if there is no actual memory populated there. Signed-off-by: Mike Rapoport Tested-by: Kefeng Wang Tested-by: Tony Lindgren Link: https://lore.kernel.org/lkml/20210630071211.21011-1-rppt@kernel.org= / Signed-off-by: Mark-PK Tsai Signed-off-by: Greg Kroah-Hartman --- arch/arm/mm/init.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) --- a/arch/arm/mm/init.c +++ b/arch/arm/mm/init.c @@ -125,11 +125,22 @@ static void __init zone_sizes_init(unsig int pfn_valid(unsigned long pfn) { phys_addr_t addr =3D __pfn_to_phys(pfn); + unsigned long pageblock_size =3D PAGE_SIZE * pageblock_nr_pages; =20 if (__phys_to_pfn(addr) !=3D pfn) return 0; =20 - return memblock_is_map_memory(addr); + /* + * If address less than pageblock_size bytes away from a present + * memory chunk there still will be a memory map entry for it + * because we round freed memory map to the pageblock boundaries. + */ + if (memblock_overlaps_region(&memblock.memory, + ALIGN_DOWN(addr, pageblock_size), + pageblock_size)) + return 1; + + return 0; } EXPORT_SYMBOL(pfn_valid); #endif Patches currently in stable-queue which might be from mark-pk.tsai@mediat= ek.com are queue-5.10/arm-extend-pfn_valid-to-take-into-account-freed-memory-map-ali= gnment.patch queue-5.10/arm-ioremap-don-t-abuse-pfn_valid-to-check-if-pfn-is-in-ram.pa= tch queue-5.10/memblock-free_unused_memmap-use-pageblock-units-instead-of-max= _order.patch queue-5.10/memblock-align-freed-memory-map-on-pageblock-boundaries-with-s= parsemem.patch queue-5.10/memblock-ensure-there-is-no-overflow-in-memblock_overlaps_regi= on.patch