Message ID | 20210518090613.21519-1-rppt@kernel.org (mailing list archive) |
---|---|
Headers | show
Return-Path: <SRS0=Yygt=KN=kvack.org=owner-linux-mm@kernel.org> X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82BDBC433ED for <linux-mm@archiver.kernel.org>; Tue, 18 May 2021 09:06:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3097E6108D for <linux-mm@archiver.kernel.org>; Tue, 18 May 2021 09:06:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3097E6108D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BAAAF6B0089; Tue, 18 May 2021 05:06:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B5A9D8E000C; Tue, 18 May 2021 05:06:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9FB2D6B008C; Tue, 18 May 2021 05:06:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id 678416B0089 for <linux-mm@kvack.org>; Tue, 18 May 2021 05:06:21 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E4FFC181AF5E6 for <linux-mm@kvack.org>; Tue, 18 May 2021 09:06:20 +0000 (UTC) X-FDA: 78153770520.21.87F6A6F Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf21.hostedemail.com (Postfix) with ESMTP id 353AAE00010A for <linux-mm@kvack.org>; Tue, 18 May 2021 09:06:20 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 7590160720; Tue, 18 May 2021 09:06:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621328779; bh=TzSLko8JIrWpgMH4yRw1BrafNW9JkoU7wGnWik8SgXI=; h=From:To:Cc:Subject:Date:From; b=R3+GEhhOSKW/448lAMB4GPAnhF+NA0EXOBRHzgsTFkGOzmGULZsyhxzBU3oeVytpL lw1zqEmpxgJjtbqCil42bs9BrYcsPrQEVxWJGkpiOicZHsRP+ikIFTl0ziVzGsqkL1 4dsxPoaJ3HP088s5XAE/GJK4mvGwESAGDWzZ4pBjS6yHd3hQKUUP35pco8UDvosNgl ZpZ+zcFIJwOS//+NHAwOcr09g0E6fI4ukRbCJjVeQEISGL1Ul5Z8F+gSIVbRxCYf6w 4BqkQwkwSa8DP+y2Lkl41EZK9fCKM/IeG/oZwzblaxO0ExSa7bYGZ5yAychdWsyPaq tJTraJZmqW9VQ== From: Mike Rapoport <rppt@kernel.org> To: linux-arm-kernel@lists.infradead.org Cc: Andrew Morton <akpm@linux-foundation.org>, Kefeng Wang <wangkefeng.wang@huawei.com>, Mike Rapoport <rppt@linux.ibm.com>, Mike Rapoport <rppt@kernel.org>, Russell King <linux@armlinux.org.uk>, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 0/3] memblock, arm: fixes for freeing of the memory map Date: Tue, 18 May 2021 12:06:10 +0300 Message-Id: <20210518090613.21519-1-rppt@kernel.org> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=R3+GEhhO; spf=pass (imf21.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-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 353AAE00010A X-Stat-Signature: 3sdr1ucx7w3gskjaa47eif33euiwprs6 X-HE-Tag: 1621328780-312684 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: <linux-mm.kvack.org> |
Series |
memblock, arm: fixes for freeing of the memory map
|
expand
|
From: Mike Rapoport <rppt@linux.ibm.com> Hi, The coordination between freeing of unused memory map, pfn_valid() and core mm assumptions about validity of the memory map in various ranges was not designed for complex layouts of the physical memory with a lot of holes all over the place. Kefen Wang reported crashes in move_freepages() on a system with the following memory layout: node 0: [mem 0x0000000080a00000-0x00000000855fffff] node 0: [mem 0x0000000086a00000-0x0000000087dfffff] node 0: [mem 0x000000008bd00000-0x000000008c4fffff] node 0: [mem 0x000000008e300000-0x000000008ecfffff] node 0: [mem 0x0000000090d00000-0x00000000bfffffff] node 0: [mem 0x00000000cc000000-0x00000000dc9fffff] node 0: [mem 0x00000000de700000-0x00000000de9fffff] node 0: [mem 0x00000000e0800000-0x00000000e0bfffff] node 0: [mem 0x00000000f4b00000-0x00000000f6ffffff] node 0: [mem 0x00000000fda00000-0x00000000ffffefff] The crashes can be mitigated by enabling CONFIG_HOLES_IN_ZONE and essentially turning pfn_valid_within() to pfn_valid() instead of having it hardwired to 1. Alternatively, we can update ARM's implementation of pfn_valid() to take into accounting rounding of the freed memory map to pageblock boundaries and make sure it returns true for PFNs that have memory map entries even if there is no physical memory. I can take the entire series via memblock tree. [1] https://lore.kernel.org/lkml/2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.com Mike Rapoport (3): memblock: free_unused_memmap: use pageblock units instead of MAX_ORDER memblock: align freed memory map on pageblock boundaries with SPARSEMEM arm: extend pfn_valid to take into accound freed memory map alignment arch/arm/mm/init.c | 15 ++++++++++++++- mm/memblock.c | 23 ++++++++++++----------- 2 files changed, 26 insertions(+), 12 deletions(-) base-commit: d07f6ca923ea0927a1024dfccafc5b53b61cfecc