From patchwork Fri Jan 5 20:14:12 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Reed X-Patchwork-Id: 1883111 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=185.125.189.65; helo=lists.ubuntu.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=patchwork.ozlabs.org) Received: from lists.ubuntu.com (lists.ubuntu.com [185.125.189.65]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4T6F6l094mz1yPK for ; Sat, 6 Jan 2024 07:14:38 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=lists.ubuntu.com) by lists.ubuntu.com with esmtp (Exim 4.86_2) (envelope-from ) id 1rLqaH-0000gj-9m; Fri, 05 Jan 2024 20:14:25 +0000 Received: from smtp-relay-internal-1.internal ([10.131.114.114] helo=smtp-relay-internal-1.canonical.com) by lists.ubuntu.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1rLqaD-0000gB-8i for kernel-team@lists.ubuntu.com; Fri, 05 Jan 2024 20:14:21 +0000 Received: from mail-yw1-f200.google.com (mail-yw1-f200.google.com [209.85.128.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 1948D3F2CD for ; Fri, 5 Jan 2024 20:14:21 +0000 (UTC) Received: by mail-yw1-f200.google.com with SMTP id 00721157ae682-5ea6aa02fa4so37130917b3.0 for ; Fri, 05 Jan 2024 12:14:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704485660; x=1705090460; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eyag5FhHmCj97VK3cQnHl2zD8ggjL9hhas/5Ll8JqwE=; b=IqqfUuPCpjcoNOwyqAe+YcqCOlMEMJh0l0Eg5tZw/9yDFcwCDDW++FIoC7cjyEcO68 aguy3+v6C6izD4Ebtz9dMuqlUFiI6zIHKbXisTXIfINtCfQs1FKzQtbH5ekN2OxVPqqH MNjak777DoAWF9pTe5dE2U7319vV5RARiA7SYmVKKhIxuQY4aQ9+3MKQLk5/sLFHuKsf SiimaD+u9L3ErffvMz8RBnonLiaylVuXA/6/Ynd5D6DJHQm4iOZFA2kzEAOwvFBHxreP sXAE/kbdi4b5tAy3I6rK12GOHKa/cH4GGuTYmL+W3vRc4gPnPa4hHDbl1YzZJ27gE7sx sTWA== X-Gm-Message-State: AOJu0YxmR3Dv5D/A1O6wTGPIwbj6uDaA+qQzDiZ/lqQSey+g/ZhBktV0 YfPn3v58FIv7VPI2xGNDo2C0xkKmsL5vKcLDI3LLo7WHqO3s6SwntKeWr1YBOSQWkDKHisuTHnr FuCWR3OKw2FYdF9ZtbYyEa1eFAdzcMqwN+rhoIZJsXVCOCNV7b89rGirN X-Received: by 2002:a81:93c2:0:b0:5d7:1941:aa6 with SMTP id k185-20020a8193c2000000b005d719410aa6mr18859ywg.65.1704485659826; Fri, 05 Jan 2024 12:14:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IG+81eyEY2MpjwhLWi0+hp8zjw4ZuhM+fqTsBj9hNiozpIqvYVFW9Gj/krABzP6/Oivx0zaVw== X-Received: by 2002:a81:93c2:0:b0:5d7:1941:aa6 with SMTP id k185-20020a8193c2000000b005d719410aa6mr18850ywg.65.1704485659344; Fri, 05 Jan 2024 12:14:19 -0800 (PST) Received: from localhost (104-54-219-103.lightspeed.austtx.sbcglobal.net. [104.54.219.103]) by smtp.gmail.com with ESMTPSA id s126-20020a817784000000b005d7647af8ccsm889840ywc.114.2024.01.05.12.14.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jan 2024 12:14:18 -0800 (PST) From: Michael Reed To: kernel-team@lists.ubuntu.com Subject: [SRU J][PATCH V3 1/1] device-dax: Fix duplicate 'hmem' device registration Date: Fri, 5 Jan 2024 14:14:12 -0600 Message-Id: <20240105201412.12441-2-michael.reed@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240105201412.12441-1-michael.reed@canonical.com> References: <20240105201412.12441-1-michael.reed@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Dan Williams BugLink: https://bugs.launchpad.net/bugs/2028158 So called "soft-reserved" memory is an EFI conventional memory range with the EFI_MEMORY_SP attribute set. That attribute indicates that the memory is not part of the platform general purpose memory pool and may want some consideration from the system administrator about whether to keep that memory set aside for dedicated access through device-dax (map a device file), or assigned to the page allocator as another general purpose memory node target. Absent an ACPI HMAT table the default device-dax registration creates coarse grained devices that are delineated by EFI Memory Map entries. With the HMAT the devices are delineated by the finer grained ranges associated with the proximity domain of the memory target. I.e. the HMAT describes the properties of performance differentiated memory and each unique performance description results in a unique target proximity domain where each memory proximity domain has an associated SRAT entry that delineates the address range. The intent was that SRAT-defined device-dax instances are registered first. Then any left-over address range with the EFI_MEMORY_SP attribute, but not covered by the SRAT, would have a coarse grained device-dax instance established. However, the scheme to detect what ranges are left to be assigned to a device was buggy and resulted in multiple overlapping device-dax instances. Fix this by using explicit tracking for which ranges have been handled. Now, this new approach may leave memory stranded in the presence of broken platform firmware that fails to fully describe all EFI_MEMORY_SP ranges in the HMAT. That requires a deeper fix if it becomes a problem in practice. Reported-by: "Tallam Mahendra Kumar" Reported-by: Mustafa Hajeer Debugged-by: Vishal Verma Tested-by: Vishal Verma Link: https://lore.kernel.org/r/166890823379.4183293.15333502171004313377.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Dan Williams (backported from commit 472faf72b33d80aa8e7a99c9410c1a23d3bf0cd8) Signed-off-by: Michael Reed [Michael Reed - resolved the conflict due to spacing. No changes to the actual patch were made] --- drivers/dax/hmem/device.c | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/drivers/dax/hmem/device.c b/drivers/dax/hmem/device.c index acf31cc1dbcc..d0f897c7f52a 100644 --- a/drivers/dax/hmem/device.c +++ b/drivers/dax/hmem/device.c @@ -8,6 +8,13 @@ static bool nohmem; module_param_named(disable, nohmem, bool, 0444); +static struct resource hmem_active = { + .name = "HMEM devices", + .start = 0, + .end = -1, + .flags = IORESOURCE_MEM, +}; + void hmem_register_device(int target_nid, struct resource *r) { /* define a clean / non-busy resource for the platform device */ @@ -41,6 +48,12 @@ void hmem_register_device(int target_nid, struct resource *r) goto out_pdev; } + if (!__request_region(&hmem_active, res.start, resource_size(&res), + dev_name(&pdev->dev), 0)) { + dev_dbg(&pdev->dev, "hmem range %pr already active\n", &res); + goto out_active; + } + pdev->dev.numa_node = numa_map_to_online_node(target_nid); info = (struct memregion_info) { .target_node = target_nid, @@ -66,22 +79,15 @@ void hmem_register_device(int target_nid, struct resource *r) return; out_resource: - put_device(&pdev->dev); + __release_region(&hmem_active, res.start, resource_size(&res)); +out_active: + platform_device_put(pdev); out_pdev: memregion_free(id); } static __init int hmem_register_one(struct resource *res, void *data) { - /* - * If the resource is not a top-level resource it was already - * assigned to a device by the HMAT parsing. - */ - if (res->parent != &iomem_resource) { - pr_info("HMEM: skip %pr, already claimed\n", res); - return 0; - } - hmem_register_device(phys_to_target_node(res->start), res); return 0;