Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp557530imm; Fri, 1 Jun 2018 05:55:21 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLJ2eRJe1ZOQ0nWfxH6dBXWHjmuR+PkCJU2FgFUPpA+0x4ziMu1oJqmVZmtNpE6kb2SqsZt X-Received: by 2002:a17:902:c6b:: with SMTP id 98-v6mr10818538pls.37.1527857721291; Fri, 01 Jun 2018 05:55:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527857721; cv=none; d=google.com; s=arc-20160816; b=buzmG38r5Eyn0kW4YFgnsEbogeR0mN3e/wOJk8mEvvuMzg9Cy4EaRtTFYv394PAU6u 1+f/yEuOF2WdNtqTHSvMKSrMF4d+93PiXCBHmVb7TjCqfX5jNlQqAZMbk/2vLcZ0UjlS h8TVuBLc6V0xQLUQcZ/IRdrnxvdGzcIoujSnPqjClUgJ7u5o99na5O9mE6pKY+3ETXsA Edv7WjcPO8wnxchw0DNpZCEZxYkLp9J1TEh4MTIdbxeEUPQqkL0Sg6CDxLVDLs+ZH9ms 8ltfhngfRUY8GvwyGEmK+Mh99nmeeIpjz95uP1GnhrPeRrFLih68UmxiLoOQjjt7wId+ 7AJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=HVZWidL1qtvKQkY/T5N9FRNZRpQ3HDSsrC9S2T24OhU=; b=VA47T6TG4IJOOSV5A0uHdKUiwAdyVhf96f2qnXSUA5kl6zEKZh6hfYxQb/y5nXT6Cb V5IZgoed39itlb4tij1dsTrcCl6wDdZJO/6SX97Btb2OwIPFv1kN87ExbJ18wMX9Gd0p g6gu1tbNaSzlvCMj8B5t5mEhMqLrGmHcDlV5cy/4KUNn5M8MNJaWComOTDcXoi+EOfGZ esK8GOeCU2RisYuur8bz5ZiSG7UnUca668ZAwcNSGytEfAYnrfDWQ0RabDE7kWudK7dS VlYpO0WypBiQsN8eGp/cDpDyzb09HOoUtqd62In5jorZAfUq4U+VeV2IL3hAZ+kZXgXQ u7rw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n64-v6si31383393pga.265.2018.06.01.05.55.07; Fri, 01 Jun 2018 05:55:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752520AbeFAMyV (ORCPT + 99 others); Fri, 1 Jun 2018 08:54:21 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:39271 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752330AbeFAMyM (ORCPT ); Fri, 1 Jun 2018 08:54:12 -0400 Received: by mail-wm0-f66.google.com with SMTP id p11-v6so1976421wmc.4 for ; Fri, 01 Jun 2018 05:54:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=HVZWidL1qtvKQkY/T5N9FRNZRpQ3HDSsrC9S2T24OhU=; b=N6I27Yk7JBjKracBKfFlwuYMVGJ6DzHkA+sfvYzSeS8D4qmTLzJk21QbwZb0GC5uWh Pi5zhqPlkHhQ4jTiaEX/1qxMrzgC23vwZjFE9U7mhdRd8Cnd1hlWSBzNH4xQBKXrcQjf SIE2pNsHSCXCX6uXEwgVjV5VgP+ne6xfxeSAlyo00vjDXtdnhaLrhtC39WE8hvqEGoXA jULwku671QjlPlYgy8WOhklvS/ZcDSJ/ZGJfv15lgHwv+P+2wsXIu5El6JY2umrIgXjR uT8WsprbfAKhHJGMAthxvVf4RkoFWTnEgyi6Zup4IKBiLXewxJUQL46y60hK1HW0xgBi EGWw== X-Gm-Message-State: APt69E2YXx09e3RaP5kZ/6SP09gRXv/hLFG9SYnMzaezA8Okh2/DKb2J QGnLTO0MUr84rgDlDpOvOBc= X-Received: by 2002:a1c:e5c5:: with SMTP id c188-v6mr2727426wmh.86.1527857650789; Fri, 01 Jun 2018 05:54:10 -0700 (PDT) Received: from techadventures.net (techadventures.net. [62.201.165.239]) by smtp.gmail.com with ESMTPSA id 135-v6sm3279251wmx.21.2018.06.01.05.54.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 05:54:09 -0700 (PDT) Received: from d104.suse.de (nat.nue.novell.com [195.135.221.2]) by techadventures.net (Postfix) with ESMTPA id DA20812317B; Fri, 1 Jun 2018 14:54:08 +0200 (CEST) From: osalvador@techadventures.net To: akpm@linux-foundation.org Cc: mhocko@suse.com, vbabka@suse.cz, pasha.tatashin@oracle.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Oscar Salvador Subject: [PATCH 2/4] mm/memory_hotplug: Call register_mem_sect_under_node Date: Fri, 1 Jun 2018 14:53:19 +0200 Message-Id: <20180601125321.30652-3-osalvador@techadventures.net> X-Mailer: git-send-email 2.13.6 In-Reply-To: <20180601125321.30652-1-osalvador@techadventures.net> References: <20180601125321.30652-1-osalvador@techadventures.net> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Oscar Salvador When hotpluging memory, it is possible that two calls are being made to register_mem_sect_under_node(). One comes from __add_section()->hotplug_memory_register() and the other from add_memory_resource()->link_mem_sections() if we had to register a new node. In case we had to register a new node, hotplug_memory_register() will only handle/allocate the memory_block's since register_mem_sect_under_node() will return right away because the node it is not online yet. I think it is better if we leave hotplug_memory_register() to handle/allocate only memory_block's and make link_mem_sections() to call register_mem_sect_under_node(). So this patch removes the call to register_mem_sect_under_node() from hotplug_memory_register(), and moves the call to link_mem_sections() out of the condition, so it will always be called. In this way we only have one place where the memory sections are registered. Signed-off-by: Oscar Salvador --- drivers/base/memory.c | 2 -- mm/memory_hotplug.c | 40 ++++++++++++++++++---------------------- 2 files changed, 18 insertions(+), 24 deletions(-) diff --git a/drivers/base/memory.c b/drivers/base/memory.c index f5e560188a18..c8a1cb0b6136 100644 --- a/drivers/base/memory.c +++ b/drivers/base/memory.c @@ -736,8 +736,6 @@ int hotplug_memory_register(int nid, struct mem_section *section) mem->section_count++; } - if (mem->section_count == sections_per_block) - ret = register_mem_sect_under_node(mem, nid, false); out: mutex_unlock(&mem_sysfs_mutex); return ret; diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 29a5fc89bdb1..f84ef96175ab 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1118,6 +1118,7 @@ int __ref add_memory_resource(int nid, struct resource *res, bool online) u64 start, size; bool new_node; int ret; + unsigned long start_pfn, nr_pages; start = res->start; size = resource_size(res); @@ -1147,34 +1148,21 @@ int __ref add_memory_resource(int nid, struct resource *res, bool online) if (ret < 0) goto error; - /* we online node here. we can't roll back from here. */ - node_set_online(nid); - if (new_node) { - unsigned long start_pfn = start >> PAGE_SHIFT; - unsigned long nr_pages = size >> PAGE_SHIFT; - + /* we online node here. we can't roll back from here. */ + node_set_online(nid); ret = __register_one_node(nid); if (ret) goto register_fail; - - /* - * link memory sections under this node. This is already - * done when creatig memory section in register_new_memory - * but that depends to have the node registered so offline - * nodes have to go through register_node. - * TODO clean up this mess. - */ - ret = link_mem_sections(nid, start_pfn, nr_pages, false); -register_fail: - /* - * If sysfs file of new node can't create, cpu on the node - * can't be hot-added. There is no rollback way now. - * So, check by BUG_ON() to catch it reluctantly.. - */ - BUG_ON(ret); } + /* link memory sections under this node.*/ + start_pfn = start >> PAGE_SHIFT; + nr_pages = size >> PAGE_SHIFT; + ret = link_mem_sections(nid, start_pfn, nr_pages, false); + if (ret) + goto register_fail; + /* create new memmap entry */ firmware_map_add_hotplug(start, start + size, "System RAM"); @@ -1185,6 +1173,14 @@ int __ref add_memory_resource(int nid, struct resource *res, bool online) goto out; +register_fail: + /* + * If sysfs file of new node can't create, cpu on the node + * can't be hot-added. There is no rollback way now. + * So, check by BUG_ON() to catch it reluctantly.. + */ + BUG_ON(ret); + error: /* rollback pgdat allocation and others */ if (new_node) -- 2.13.6