From patchwork Fri Jun 22 11:18:37 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Oscar Salvador X-Patchwork-Id: 10481891 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id B74C560230 for ; Fri, 22 Jun 2018 11:19:38 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A0E9B28BCD for ; Fri, 22 Jun 2018 11:19:38 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 955D728C22; Fri, 22 Jun 2018 11:19:38 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 194F028BCD for ; Fri, 22 Jun 2018 11:19:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 79BBA6B000C; Fri, 22 Jun 2018 07:19:35 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 7257D6B000D; Fri, 22 Jun 2018 07:19:35 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EC0B6B000E; Fri, 22 Jun 2018 07:19:35 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id ECA996B000C for ; Fri, 22 Jun 2018 07:19:34 -0400 (EDT) Received: by mail-wm0-f70.google.com with SMTP id g73-v6so993523wmc.5 for ; Fri, 22 Jun 2018 04:19:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:to:cc :subject:date:message-id:in-reply-to:references; bh=NBKT+5JUwQw/r3C6aqXjbsngiM0nuvCN+1pO6/0lpaY=; b=NlXE57ATXiSOAJUiYMb7HcJQxNbOmCRhtD7Pyy0wKFZ8kz0VE4P0+sIFOeOVI8OPgT nZTWCqteJXlMIjA9x45LTkRzuP47yfbQEqBEay+c8TXFgkfUh8XaUOvbg1L6pr+VhW5W PDAFwGJIxOAD/MNS5vhjN0Uo5H0gL7rtRcJn+vpLgzavTDNNaodD1CXQKwIBLsc8qbEo UkCK94ZnB69G1d6vGI/yJM3HjNnEn3o3fGhJ4csiYtmqnIjXKp4ym6gdbJI77ONOphbF SBeVpzOlW+TZo1Ei3M0xTYYp+GYuZJmq0qgvTcRcL8aqxXY75Gz28jsydBx1GKhr8ssb S2Rg== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of osalvador.vilardaga@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=osalvador.vilardaga@gmail.com X-Gm-Message-State: APt69E0uV69gx0puW3WQjIVEboOnzXlFs6qzs+lcazM234zOw/M+Kn1T 63OaawuiZ9/marRfb/sEU5RnxFStITmtl4+09GeBzkqbphpMGNxIvIZqLDaTVQEuAyLbP7osek+ dhZnBt4/xXGqKW67+q+Pbd97upJ7LeHKFyMEntoIsoy3sRAt85RFowG/USqYWln3Xfbqe6niwLQ AR7OHp87aRjBysZfZjkGWqOTk/neHqaCoaehpj79E2zHPv0f1/6nOzIBZt9qg5l0SWb4rxAnIMc DZVmPL71vo2M+OnzkLoD3DSFb6WxAJPUKbU7Nm8w7hm4non62Yb5dQ3czkfmOdQhmVInOdFPZst b5iNfJOhaQMzCzUvIYlw/P671reVGWD1IgAgMuaI2qdmiPCswldBrNf4UUBgNXZ9/8bjj151/Q= = X-Received: by 2002:a1c:f906:: with SMTP id x6-v6mr1396028wmh.63.1529666374504; Fri, 22 Jun 2018 04:19:34 -0700 (PDT) X-Received: by 2002:a1c:f906:: with SMTP id x6-v6mr1395991wmh.63.1529666373756; Fri, 22 Jun 2018 04:19:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529666373; cv=none; d=google.com; s=arc-20160816; b=yt3OK0UtKk3hPOqGw/ajXaL1xAvLV4hJffQeMDiZnI+rEbqHsgpWznvv4kAmMoiVIm XoOuUEDsDnfe9QCIO2a47joC8vWKglfsseY4p0KSH6flAbEcDLL1fshx011GikghsOqv X1IJ/HWKTGynhHI6VglzhW6Jcwe4SD7y5gZA8O5sxUFkiIgu2c7FICK0covKq4B6ku7g lqbdL+usF0wZ8Sjl2E8++h1SuV1E5QqqVtglu5/L8OdrsHGnt87GjMwfVub3grW5PrJb phV0OkjoHF3j28n0cRVb1Ov+1Cd4UPC5wsc5XSxwEEUlWRxs3HAvlUkH8lCZ9WbJBtYA 8cXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=NBKT+5JUwQw/r3C6aqXjbsngiM0nuvCN+1pO6/0lpaY=; b=Ov27mS+iF8hKfdIfvHjlOM7Ia6ipPsn0mRU4l+u39/nwSHmQi2ZhGMgiTjTmNLy69+ Kw3T/eyjBrjiFlH2DuTgj8kW2dRtFT2DNUpwp9qdXoSe5w9XvmV9t013qo6VkKMMStvG ZHn2rWbn21AUacy2j9KM/X/gMxyTyPrRyJ+71k5KuGTPOhoPSikH2bMfUQ3Z6ABG5xrL jOVKlYfp3P71xtUHZcDcQCEY+9vEtjLx3nikhpF/SWZ9tdbUfhopGo7iq29CdH+27I8d x1vD0MWghWZdAbRkhM5hNbwFeWR0FJ/bc35mMTaytefONojaVZNNwMvYKwSKfc+NMxcA DPrw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of osalvador.vilardaga@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=osalvador.vilardaga@gmail.com Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id p63-v6sor452513wmf.28.2018.06.22.04.19.33 for (Google Transport Security); Fri, 22 Jun 2018 04:19:33 -0700 (PDT) Received-SPF: pass (google.com: domain of osalvador.vilardaga@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; spf=pass (google.com: domain of osalvador.vilardaga@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=osalvador.vilardaga@gmail.com X-Google-Smtp-Source: ADUXVKIS6vCu51yWAt/91xx+8dTae8Jw3RsPy60TQlqakeJdDL+jE0vf2E4WVFURmo1Z36Q4A27wOw== X-Received: by 2002:a1c:9514:: with SMTP id x20-v6mr1484037wmd.76.1529666373481; Fri, 22 Jun 2018 04:19:33 -0700 (PDT) Received: from techadventures.net (techadventures.net. [62.201.165.239]) by smtp.gmail.com with ESMTPSA id 203-v6sm1907128wmp.23.2018.06.22.04.19.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jun 2018 04:19:32 -0700 (PDT) Received: from d104.suse.de (charybdis-ext.suse.de [195.135.221.2]) by techadventures.net (Postfix) with ESMTPA id B82FA12375B; Fri, 22 Jun 2018 13:19:31 +0200 (CEST) From: osalvador@techadventures.net To: akpm@linux-foundation.org Cc: mhocko@suse.com, vbabka@suse.cz, pasha.tatashin@oracle.com, Jonathan.Cameron@huawei.com, arbab@linux.vnet.ibm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Oscar Salvador Subject: [PATCH v2 2/4] mm/memory_hotplug: Call register_mem_sect_under_node Date: Fri, 22 Jun 2018 13:18:37 +0200 Message-Id: <20180622111839.10071-3-osalvador@techadventures.net> X-Mailer: git-send-email 2.13.6 In-Reply-To: <20180622111839.10071-1-osalvador@techadventures.net> References: <20180622111839.10071-1-osalvador@techadventures.net> 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: X-Virus-Scanned: ClamAV using ClamSMTP 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 Reviewed-by: Pavel Tatashin --- drivers/base/memory.c | 2 -- mm/memory_hotplug.c | 32 +++++++++++--------------------- 2 files changed, 11 insertions(+), 23 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 504ba120bdfc..e2ed64b994e5 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1123,6 +1123,7 @@ int __ref add_memory_resource(int nid, struct resource *res, bool online) u64 start, size; bool new_node = false; int ret; + unsigned long start_pfn, nr_pages; start = res->start; size = resource_size(res); @@ -1151,34 +1152,23 @@ 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; - - 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 + /* If sysfs file of new node can't be created, cpu on the node * can't be hot-added. There is no rollback way now. * So, check by BUG_ON() to catch it reluctantly.. + * We online node here. We can't roll back from here. */ + node_set_online(nid); + ret = __register_one_node(nid); 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); + BUG_ON(ret); + /* create new memmap entry */ firmware_map_add_hotplug(start, start + size, "System RAM");