Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp352947pxv; Wed, 14 Jul 2021 05:39:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw9wZOl3bQWMCzBEh1T70L50vf/Tpf+91W3WuANRxRB0Cje8BoFs0RdmP7fME1K+AAZBFuh X-Received: by 2002:a05:6402:c96:: with SMTP id cm22mr13012601edb.132.1626266344572; Wed, 14 Jul 2021 05:39:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626266344; cv=none; d=google.com; s=arc-20160816; b=jH3aISD1Aev1F38ulYuIq/XO5mB9402txEUVYX0isZWfx2CftVYxIscZ2bRjJoW6xe 0aePg0tU79x9kPoVQKXKg97lPJ4Qd06G453+/z2U/k1FCzqFdLUExku3dD3g+bGpA5WR 3nnoRU/Jq4KrVITKlrfOvlIS3rY+W+XF8Qxx7kFYLaTjALPBkppkmHL+rM5+OVSPWdrX JC/bSDNSa9ASm+wm715nLABqJr8q7K5w9RmBykcVHJTOa+gDP6CP+oFbGxp/ne/KE6g1 XfWMm5mkPduMmxSaZHiZRb9XxPdvM+3oqzEST6odEURtCgo6Hv6HZpGUUgWKvL9h+bh6 zArQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=NfqI6oqFsuur6C4N8ABcPfet12fhh4Ven8KCpp4NFFw=; b=zlGuWMWjV9u/m74erqSOaGrIBISPm1be+0QoWOM9LrQT9FAjLUrwdiH7PLNfwKSBwm AL/DYFqJLwrBcErz8z3uUh6cM3ew/2FKIQCNH7kYpLR4NrkO9J1dhmmsEo6MJTuQzvNr a8hMqjlWFc8sIZqmF6p09jHb7IuYKXxcUlMv/FSrtfVZcwlKVDgWjKhXxtl1RqernD1E +Efhs0g/O6sLYd8VeuQFVksopxNvpZhNQt8Y1cugymdf+yL9NKHBzRfN1go2b3gvzFNI q3C+x+Ht6rNWy2dTZN7vKR7ABmwRzm+Ja8DqZxbFwXbBJB8cs7Aj0WZotg+bXdtH/XC4 a0dw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=HLXH1K30; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v4si2976040edj.103.2021.07.14.05.38.42; Wed, 14 Jul 2021 05:39:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=HLXH1K30; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239321AbhGNMkh (ORCPT + 99 others); Wed, 14 Jul 2021 08:40:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:56290 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239284AbhGNMkh (ORCPT ); Wed, 14 Jul 2021 08:40:37 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id EA3FA613B2; Wed, 14 Jul 2021 12:37:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626266265; bh=MyPP3ysLnfTJLvyibD3l2UlFIkzFdXWBmuEZG/TSVPk=; h=From:To:Cc:Subject:Date:From; b=HLXH1K30fK5FCwC5EXrm1k4OgLay4d4qd027S0BgGNFmI6CRmAg4Iqaxv1EX6Rg7B LgEomgvD5TucICoERiWzby1PiLf779f5ri3KJZLLmJVbykiD2bzRtUZs/z2/cbGg2A WsUzLOVfq3aHS2grHWyDHdzURJbOFhAB0qPBDS19LxbdEKpKZSV5cDJk4GMC8i50qm phoXbyadDg/N52auD39g9iOh6QwHfXLgx9U4sGA2bkiHDViUrZd8Az76ltdKB/nTau 1eZLOn3/ALZ37UB3PBrSYxscFkfCv5PJ8x4vAn5bnDglEJkC7KaVp2BRVq8Cqfq7lC dJvEMEAOnOn7A== From: Mike Rapoport To: Andrew Morton Cc: Michal Simek , Mike Rapoport , Mike Rapoport , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 0/4] mm: ensure consistency of memory map poisoning Date: Wed, 14 Jul 2021 15:37:35 +0300 Message-Id: <20210714123739.16493-1-rppt@kernel.org> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mike Rapoport Hi, Currently memory map allocation for FLATMEM case does not poison the struct pages regardless of CONFIG_PAGE_POISON setting. This happens because allocation of the memory map for FLATMEM and SPARSMEM use different memblock functions and those that are used for SPARSMEM case (namely memblock_alloc_try_nid_raw() and memblock_alloc_exact_nid_raw()) implicitly poison the allocated memory. Another side effect of this implicit poisoning is that early setup code that uses the same functions to allocate memory burns cycles for the memory poisoning even if it was not intended. These patches introduce memmap_alloc() wrapper that ensure that the memory map allocation is consistent for different memory models. Mike Rapoport (4): mm/page_alloc: always initialize memory map for the holes microblaze: simplify pte_alloc_one_kernel() mm: introduce memmap_alloc() to unify memory map allocation memblock: stop poisoning raw allocations arch/microblaze/include/asm/pgtable.h | 2 -- arch/microblaze/mm/init.c | 12 ---------- arch/microblaze/mm/pgtable.c | 17 +++++++------- mm/internal.h | 4 ++++ mm/memblock.c | 20 ++++------------- mm/page_alloc.c | 32 ++++++++++++++++++--------- mm/sparse.c | 6 ++--- 7 files changed, 40 insertions(+), 53 deletions(-) base-commit: e73f0f0ee7541171d89f2e2491130c7771ba58d3 -- 2.28.0