Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp2734771pxb; Mon, 31 Jan 2022 03:11:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJy+jxjnZgOzql6kOIt6PSkycdTrgPJT8aIrdMNUTwnpEJuXTniVLN2EWPpxAnfofqf0Dc5z X-Received: by 2002:a17:90b:390a:: with SMTP id ob10mr33647584pjb.92.1643627516975; Mon, 31 Jan 2022 03:11:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643627516; cv=none; d=google.com; s=arc-20160816; b=iQbMaXhqHMsd6a5ap9NF0/G5IYf3V4Vc28yIKsbcTcbs3S5IRy0/T+nKL7lCLKozF+ kklYFEzxoCj//2/dWuj2zDK9ByfXMv1VfLeVIJx4k6Ua8qSTsW+gmHxlAeh37e9RqU8y zAlJLy/7glFNtcMv9UiitnXoI7FI3FhdJYo4o/ZI6AjzBQFYb/w8XB/XS65qMxsDehVB IRiZsYGms21vwlptdbFq8Umev5V8AWbXmbGa+571rcJGi8X9VeYsFf7jBXz4NiUTWAs/ ISWh3GzVkXc3LHufs+ug24IDcP9QTPs3BborCmqQVTAY4c0PUCFvZqufEqKDCR13gX5O /jFQ== 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=5TByn2+H7Z/Q1nf1GVCZH5w6HMAy4Lol4pqxeNfQkI8=; b=QBj5u+tYHGshZYYgfkdX2WFftWpKaMstpNB5e8bmkEv8eGzrz0py2d7D3FYOgy00/X JRBTF2S5jJ3Qm4IPuTe3IC7QiUA8g2aVoh7BZUmL2B3LqYVU1IF31gy7FNnD32SW04gI vjPd/IDpgp5/M0HEFn0xrCGlvW624M4gMA0QRl+u7l4uCl8JdEkZnLEv9/SrMYaEb5Qa EYm7MCG5FuesNQ5VjSEsOLT3YtIR4Kd1Tvkvv7epvftEY7JZGhrPze9+r21Ffjbnr+hN m2fpr0fh8rm5S0utm0xH0BBKrecwxwjXh3TO/OnJcWuRbR+1dehpUX7hUD8bM7YyarED h1zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HtUO4OrN; 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 20si13585289pgk.876.2022.01.31.03.11.46; Mon, 31 Jan 2022 03:11:56 -0800 (PST) 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=@redhat.com header.s=mimecast20190719 header.b=HtUO4OrN; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349286AbiA1P0f (ORCPT + 99 others); Fri, 28 Jan 2022 10:26:35 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:48554 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232396AbiA1P0d (ORCPT ); Fri, 28 Jan 2022 10:26:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643383592; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=5TByn2+H7Z/Q1nf1GVCZH5w6HMAy4Lol4pqxeNfQkI8=; b=HtUO4OrNdT+FDnrW3pgYOpj1XWmQ2GN8BXSvIo2WHm9kWKO64E00t/NDxyrEoBKWsFkX/A Z3O+P1TevUSARy7Tlc9zuuAFOfsAdPx1oexzTMAxhCY1zPi+GRH4pytK60jmuyBGEQM1jU CVHg3JLRDz6Z/GQWxEVRLQojSJlZL0s= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-444-TPK6_5vpODm541tbgA5WSA-1; Fri, 28 Jan 2022 10:26:29 -0500 X-MC-Unique: TPK6_5vpODm541tbgA5WSA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0A695100CCC2; Fri, 28 Jan 2022 15:26:28 +0000 (UTC) Received: from t480s.redhat.com (unknown [10.39.193.182]) by smtp.corp.redhat.com (Postfix) with ESMTP id F01307CAD6; Fri, 28 Jan 2022 15:26:21 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, David Hildenbrand , Andrew Morton , "Rafael J. Wysocki" , Greg Kroah-Hartman , Michal Hocko , Oscar Salvador Subject: [PATCH v1 0/2] drivers/base/memory: determine and store zone for single-zone memory blocks Date: Fri, 28 Jan 2022 16:26:18 +0100 Message-Id: <20220128152620.168715-1-david@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is based on v5.17-rc1 and: * [PATCH v1] drivers/base/memory: add memory block to memory group after registration succeeded [1] * [PATCH RFC v1] drivers/base/node: consolidate node device subsystem initialization in node_dev_init() [2] -- I remember talking to Michal in the past about removing test_pages_in_a_zone(), which we use for: * verifying that a memory block we intend to offline is really only managed by a single zone. We don't support offlining of memory blocks that are managed by multiple zones (e.g., multiple nodes, DMA and DMA32) * exposing that zone to user space via /sys/devices/system/memory/memory*/valid_zones Now that I identified some more cases where test_pages_in_a_zone() might go wrong, and we received an UBSAN report (see patch #3), let's get rid of this PFN walker. So instead of detecting the zone at runtime with test_pages_in_a_zone() by scanning the memmap, let's determine and remember for each memory block if it's managed by a single zone. The stored zone can then be used for the above two cases, avoiding a manual lookup using test_pages_in_a_zone(). This avoids eventually stumbling over uninitialized memmaps in corner cases, especially when ZONE_DEVICE ranges partly fall into memory block (that are responsible for managing System RAM). Handling memory onlining is easy, because we online to exactly one zone. Handling boot memory is more tricky, because we want to avoid scanning all zones of all nodes to detect possible zones that overlap with the physical memory region of interest. Fortunately, we already have code that determines the applicable nodes for a memory block, to create sysfs links -- we'll hook into that. Patch #1 is a simple cleanup I had laying around for a longer time. Patch #2 contains the main logic to remove test_pages_in_a_zone() and further details. In theory, we could do without [2], however, with a consolidated node device initialization logic it's easier to verify that we actually have the information we need (NIDs for memory blocks) around at the right time and before anything else might rely on it. [1] https://lkml.kernel.org/r/20220128144540.153902-1-david@redhat.com [2] https://lkml.kernel.org/r/20220128151540.164759-1-david@redhat.com Cc: Andrew Morton Cc: "Rafael J. Wysocki" Cc: Greg Kroah-Hartman Cc: Michal Hocko Cc: Oscar Salvador David Hildenbrand (2): drivers/base/node: rename link_mem_sections() to register_memory_block_under_node() drivers/base/memory: determine and store zone for single-zone memory blocks drivers/base/memory.c | 92 ++++++++++++++++++++++++++++++++-- drivers/base/node.c | 18 +++---- include/linux/memory.h | 13 +++++ include/linux/memory_hotplug.h | 6 +-- include/linux/node.h | 16 +++--- mm/memory_hotplug.c | 58 ++++----------------- 6 files changed, 127 insertions(+), 76 deletions(-) -- 2.34.1