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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 57A3CC433EF for ; Thu, 11 Nov 2021 09:46:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E621D6109D for ; Thu, 11 Nov 2021 09:46:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E621D6109D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 7BAF56B0092; Thu, 11 Nov 2021 04:46:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 76A676B0093; Thu, 11 Nov 2021 04:46:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 658AD6B0095; Thu, 11 Nov 2021 04:46:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) by kanga.kvack.org (Postfix) with ESMTP id 53B936B0092 for ; Thu, 11 Nov 2021 04:46:06 -0500 (EST) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1252982D8B for ; Thu, 11 Nov 2021 09:46:06 +0000 (UTC) X-FDA: 78796168332.31.ED62147 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf31.hostedemail.com (Postfix) with ESMTP id 4F30D104D40C for ; Thu, 11 Nov 2021 09:45:52 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id A2F11610FC; Thu, 11 Nov 2021 09:46:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636623964; bh=3OLkwWk/NZSEDP1NahNmJ1beXxLc2iY3gP7DvD9SdqQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ux8c7LmhPMx5KGDLJ6Ojw2y7xqoSoecV35sIZjwzPqzL1QKOShaAsGKx69Ld4/pf7 44BuT/wWaXUXkZkdCEcLenUyD6XsNn5Fz9GdC+xvOkKQ9NvcJZV/7YjdObWOCntBO2 PvvYLzN+I949FUOnZCBuQAiss+0OszfAB8B9d1BgvyQ96/hlTJYKY+M8Yit7cEXbDg ns3EK+/1Epk9PNA79YIDNi7QtEA9uyYDQx0nckxAJJX3HhpBIqxy1Ls033vkb2t3P1 +gIQdg+CboASafJvmX4e/g9zq7M0yZs47x+wyWYymopxybNRNkUf0X1j7nussDgLOa E1b2uOFJBGh0A== Date: Thu, 11 Nov 2021 11:45:56 +0200 From: Mike Rapoport To: Mark-PK Tsai Cc: akpm@linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux@armlinux.org.uk, rppt@linux.ibm.com, tony@atomide.com, wangkefeng.wang@huawei.com, yj.chiang@mediatek.com Subject: Re: [PATCH v3 0/4] memblock, arm: fixes for freeing of the memory map Message-ID: References: <20210630071211.21011-1-rppt@kernel.org> <20211111073329.13095-1-mark-pk.tsai@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211111073329.13095-1-mark-pk.tsai@mediatek.com> X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 4F30D104D40C X-Stat-Signature: cru1b674femkpsmjp8y33pt6tomnmhyi Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Ux8c7Lmh; spf=pass (imf31.hostedemail.com: domain of rppt@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1636623952-932899 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, On Thu, Nov 11, 2021 at 03:33:29PM +0800, Mark-PK Tsai wrote: > Hi, > > The lts kernel also have this issue. (we use 5.4-lts kernel.) > Currently we patch our custom kernel to select CONFIG_HOLES_IN_ZONE for arch arm. > But I think the formal solution should backport to lts. > > Would you help to backport this patch series? (including the below commit) There were a couple of changes between 5.4 and this set, so you'd need to "apply" the first two patches to arm::free_unused_memmap(). Other than that, I don't see any pitfalls here. Feel free to CC me when you post the backported series. > (024591f9a6e0 arm: ioremap: don't abuse pfn_valid() to check if pfn is in RAM) > > Thanks! -- Sincerely yours, Mike.