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 1036AC83F1A for ; Mon, 21 Jul 2025 05:09:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36E716B008A; Mon, 21 Jul 2025 01:09:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31E5C6B008C; Mon, 21 Jul 2025 01:09:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 234566B0093; Mon, 21 Jul 2025 01:09:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 13CDD6B008A for ; Mon, 21 Jul 2025 01:09:11 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 951DE160502 for ; Mon, 21 Jul 2025 05:09:10 +0000 (UTC) X-FDA: 83687092860.08.FC38736 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf28.hostedemail.com (Postfix) with ESMTP id DDA41C0003 for ; Mon, 21 Jul 2025 05:09:08 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Mah+Tghr; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf28.hostedemail.com: domain of ardb@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=ardb@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1753074548; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=dy9aGz9vC+Li04RRXcqqednXKHx5gfuIHxiNc5T2Ljs=; b=QPGLTcZyaBiJSoGbikSmFE1tRd7pynsUsjwoZwTCaQAaD7vVPrVZnK0SklkinEXwvQsGhh 3nQFpkUJchLxoFazzha9pJQez6r52pyZOQzxgJr1eei8u1bgQ72A9VJAjKVir/U5ieHucW B1A8ZWTa8Ejtr3MZKzp5AI7xiRjshkE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1753074548; a=rsa-sha256; cv=none; b=a+YeP7q9LXa0f/Ol+qDnyVerasVwSdH1RqxqOxZZU5KvN120vMMcK5I1efHJqdcfa4opNJ Ur2bpbsdCVELJBAbriyYheG8JtejpM+jmzs/nVcCbsj4jVBegU9gzpRtRmASX1kz3tbyVy JAZN3LBu9Oz70fYUZLyYmppzC2fKYHw= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Mah+Tghr; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf28.hostedemail.com: domain of ardb@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=ardb@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 1A7FA600AE for ; Mon, 21 Jul 2025 05:09:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5F55C4CEF4 for ; Mon, 21 Jul 2025 05:09:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1753074547; bh=mE6jUqCRnNUpD+/Q0rPego09ThKwPBZs/426+KQcfyw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Mah+TghrNtwzwFL2YeU8BYyG7cm4yPMT2oOQaYmoXjilYBCuXMG5hV2sDbjf0QKK9 9dAryw9R3Gb9eP5dSQIcOXCX5HawRSSNMa4TbfhjnP2loObF5WavLLquLohDgxP6u8 BdhmLfgVoyXCjbVndnLTrGeOObENJSFsDLDYMTX9CknhWsFTM9MFDkfOwYhGCoTzLp s6ILwjcCiahlgKKFvy6b2E07lmRklDOUFC1p9Im76SZEeVd99R9KTN7UNWMKFCV9nt dZr4cXBl+QPlkr5IzuAAf8PgGB5V+QBGSjNpAniQ7EyrCJRifrvSCe6b5SOx3y+R5k 4RXTlG+h04/ig== Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-32cdc9544ceso34784941fa.0 for ; Sun, 20 Jul 2025 22:09:07 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVXKDWLwlIoDQB+E1rebSeKeoLxH4k8REOVOxXhom4uijkk1zwozu65CTga73casxfSTkioYk9aRA==@kvack.org X-Gm-Message-State: AOJu0YyXlSYX9rhDgSl0Ir2vRFHS4HDrkgfv0yuDYgu2VsPs55x8F5hi M4PRO2fLHlamgVCyV/Ol6D7CBbt/niDbHBWcGZiyUiBh0OjaImJRe3W6Xml8QJEie8R/1LRSVs3 cIaJIJU1dw0fCPLiok6daBvQKoU/Ype4= X-Google-Smtp-Source: AGHT+IFQLtKd8Waolhv9mmK7mca11jQhwiRk4Ud79gugVJQSJ6QSPxdCJsPLq/8Lt/at84+JOinIuRHo2NyRM9eTTq4= X-Received: by 2002:a05:651c:1488:b0:32b:2ea9:1dcd with SMTP id 38308e7fff4ca-3308f60eb32mr47084441fa.32.1753074546096; Sun, 20 Jul 2025 22:09:06 -0700 (PDT) MIME-Version: 1.0 References: <20250717085723.1875462-1-mawupeng1@huawei.com> <9688e968-e9af-4143-b550-16c02a0b4ceb@huawei.com> <8d604308-36d3-4b55-8ddb-b33f8b586c1a@huawei.com> In-Reply-To: From: Ard Biesheuvel Date: Mon, 21 Jul 2025 15:08:48 +1000 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXyjqTH9Bay5BBZMJnmEAkp89_i1OwrVdu4kl7-wlrSbkPihr_WXFGx5kTw Message-ID: Subject: Re: [PATCH] mm: ignore nomap memory during mirror init To: Mike Rapoport Cc: mawupeng , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: DDA41C0003 X-Stat-Signature: 7nddc4pextsjthbzkk7p8tm34b3kqc17 X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1753074548-433273 X-HE-Meta: U2FsdGVkX1/RoETzL9BIeZaURgmvkcqmtexoEHulvajoJ+DMzmNsCGv3Z+lOEU5ZEykFnSsa5vOijA7VFeCcJAsA4rvNeFXzL+ykveiFRDCD9UKm9fzhSJNhlqN2CSspFIFzTC9wjo5s48xAq6Mj0O26JSJdWkl50r+ywWNnID8nNLQct9+av/pBy9zR3DyU2bzNx3smUDeqqCB5UrylI4zG17nZT8XuxVE3JZANSn8zRYh5+rLZKsThM7Jz+WKE3lxvTFypbhtK+9X0zvgZgugCMesiDoFqbJcwqOj9qN8GFfOjhrcnfZV55GdNTSd9B98+dnQ0aj31njwfyLIcyVr1nV6YfTT46+9dEfqzzqaKTdulB3k3f2MfOzOYngaFg+5OTxCG3RLdWHYVWen+aMnEhergInC6v4YefgQCuYAuTzRk56J9uUrKrz/ojrWmgfezaxqLvHjxYftAG4Cu0B8pUFNrB8DEwiasV5l5ERoke2aYUBP7/oTCG5wtmmowfUSNMqeYXYoCPfiTO9uzdo5ZXxVvyU66ZnLlt/vCIpe/vcyrw1Y/tOhtirvvnEmvTr/DcX/dSdTIfp2/9V82GwSTrzN5IwcOCTl5NCVKqoyVt5lavtX850QdlQHW1u5uj0bR5945KE2+y4eC/iaaPMjH8p4ZN4zWGy3d43/rGALdwWZJWF4/AEaXtpv5H+FusN3EcnthUp966gtQPjovXHS5PUZBn4hnV37Ze88CTYtjfJ8Z3ca3GI7SUZx0V4Q0HkDAWiD/MKbPOrv+iMZZ80RGuk+EeVyKUosdfDpmraHaKn4wwax0qe3n3d3ImDBUwdFceZ761coIkbAci7sLUAdrG3EeuWh1s43Xa7buwuZ5/EqCNIgx0kSiUXzWWnUaj3fDrS+waqB8ppmziAQW6qkXmHuSweYd/2F7WgO1Jcl6Q1IvF3btEkKJWqR3eKaTLdo1q9xcPKs= 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: List-Subscribe: List-Unsubscribe: On Sun, 20 Jul 2025 at 22:38, Mike Rapoport wrote: > ... > > > w/o this patch > > [root@localhost ~]# lsmem --output-all > > RANGE SIZE STATE REMOVABLE BLOCK NODE ZONES > > 0x0000084000000000-0x00000847ffffffff 32G online yes 67584-67839 0 Movable > > 0x0000085000000000-0x0000085fffffffff 64G online yes 68096-68607 0 Movable > > > > w/ this patch > > [root@localhost ~]# lsmem --output-all > > RANGE SIZE STATE REMOVABLE BLOCK NODE ZONES > > 0x0000084000000000-0x00000847ffffffff 32G online yes 8448-8479 0 Normal > > 0x0000085000000000-0x0000085fffffffff 64G online yes 8512-8575 0 Movable > > As I see the problem, you have a problematic firmware that fails to report > memory as mirrored because it reserved for firmware own use. This causes > for non-mirrored memory to appear before mirrored memory. And this breaks > an assumption in find_zone_movable_pfns_for_nodes() that mirrored memory > always has lower addresses than non-mirrored memory and you end up wiht > having all the memory in movable zone. > That assumption seems highly problematic to me on non-x86 architectures: why should mirrored (or 'more reliable' in EFI speak) memory always appear before ordinary memory in the physical memory map? > So to workaround this firmware issue you propose a hack that would skip > NOMAP regions while calculating zone_movable_pfn because your particular > firmware reports the reserved mirrored memory as NOMAP. > NOMAP is a Linux construct - the particular firmware reports a 'reserved' memory region, but other more widely used memory types such as EfiRuntimeServicesCode or *Data would result in an omitted region as well, and can appear anywhere in the physical memory map. There is no requirement for the firmware to do anything here wrt the MORE_RELIABLE attribute even though such regions may be carved out of a block of memory that is reported as such to the OS. So I agree with Wupeng Ma that there is an issue here: reporting it as mirrored even though it is reserved should not be needed to prevent the kernel from mishandling it.