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 BCF84C433EF for ; Wed, 15 Dec 2021 14:10:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 446AE6B0071; Wed, 15 Dec 2021 09:10:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F75F6B0073; Wed, 15 Dec 2021 09:10:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E5B36B0074; Wed, 15 Dec 2021 09:10:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0067.hostedemail.com [216.40.44.67]) by kanga.kvack.org (Postfix) with ESMTP id 20D9B6B0071 for ; Wed, 15 Dec 2021 09:10:10 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id DF5FC441A for ; Wed, 15 Dec 2021 14:09:59 +0000 (UTC) X-FDA: 78920212518.12.01DAA89 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf04.hostedemail.com (Postfix) with ESMTP id 0FD7640015 for ; Wed, 15 Dec 2021 14:09:58 +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 411CFB81F22; Wed, 15 Dec 2021 14:09:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7FDA3C34605; Wed, 15 Dec 2021 14:09:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1639577395; bh=0Xd0vD+dMoDhwSMrtuvnc9mmfRuwo308rQ8zHutvDX0=; h=Subject:To:Cc:From:Date:In-Reply-To:From; b=V0FsNDa/pRt9K8W4JRvIJLpSm//cjVVZ74ugrfBQfyEN0kk4KRZbUpMO5Dyh2AIkc Zj9AtO4p3G3PH/LV8JyYDke35CCmwzTaFCT4yyEXclsIG+VbPT3ymn7Chapsb2adMF Y8RV0zku2CwnLOzWTw5NeP2+OnJx2Fft0brPzAp4= Subject: Patch "arm: extend pfn_valid to take into account freed memory map alignment" has been added to the 5.4-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:09:52 +0100 In-Reply-To: <20211213085710.28962-5-mark-pk.tsai@mediatek.com> Message-ID: <163957739216183@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 X-stable: commit X-Patchwork-Hint: ignore X-Rspamd-Queue-Id: 0FD7640015 X-Stat-Signature: 7ar4cy3b7mfm37csacaap5hwc1gna9so Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b="V0FsNDa/"; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf04.hostedemail.com: domain of gregkh@linuxfoundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org X-Rspamd-Server: rspam11 X-HE-Tag: 1639577398-654962 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.4-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.4 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:02:39 PM CET 2021 From: Mark-PK Tsai Date: Mon, 13 Dec 2021 16:57:09 +0800 Subject: arm: extend pfn_valid to take into account freed memory map alig= nment To: Cc: , , , , , = , , , , , Message-ID: <20211213085710.28962-5-mark-pk.tsai@mediatek.com> From: Mike Rapoport commit a4d5613c4dc6d413e0733e37db9d116a2a36b9f3 upstream. 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 @@ -176,11 +176,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(__pfn_to_phys(pfn)); + /* + * 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.4/arm-extend-pfn_valid-to-take-into-account-freed-memory-map-alig= nment.patch queue-5.4/arm-ioremap-don-t-abuse-pfn_valid-to-check-if-pfn-is-in-ram.pat= ch queue-5.4/memblock-free_unused_memmap-use-pageblock-units-instead-of-max_= order.patch queue-5.4/memblock-align-freed-memory-map-on-pageblock-boundaries-with-sp= arsemem.patch queue-5.4/memblock-ensure-there-is-no-overflow-in-memblock_overlaps_regio= n.patch