Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1451574imm; Wed, 20 Jun 2018 19:04:46 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIFmfmp8pPrQ046mdSePBpjN3sMJDhQNjVcHXi3i7vW2OSQV2A9p/1Qs+MclX4NfGnCvFqo X-Received: by 2002:a65:6310:: with SMTP id g16-v6mr20993373pgv.271.1529546686899; Wed, 20 Jun 2018 19:04:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529546686; cv=none; d=google.com; s=arc-20160816; b=09Zd3//po/nsuvP4re0bHbNhiOQiRQoBZjqexkqIOlPs1QCFLVYA5uv5Ex+DdBELar NRjcYat5Tzu02HpyV0IxOyBiHJbqimRxRGg0CdSJweCpD1zY89xBB8fklWi1FlQGTzkA iDIiJ6pZJDHpjmdga3UeXyRqHBPddAPaqYEz+u3zsf+B4F6RKM9mjd5onpTp1quhXCXt YuKA+R+9hjtto+ke1bk/8xvrpKr0SuiZ0hPaDF03kBVKDmQEZ1e18tRYCBiwJKku1k/9 lUjAyA0YczKlI8DhkmMHUjIUjnKPUqEwztrhe8nUv7A02P36OSE8U28TufXD5OvFWHBY lVBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=bPDabLFm/GD1lN7nSnmXAAMn5M+wEK6RlHiUeWSevoE=; b=uoy2aKCBO4UyL34H7gQql2pjIB+qhFIPEbeWtOflyGxCjjNXcCKKSjdZhMA1VA1gcN 0GIFU7e8SlEMH8unmgFOvWqeOzdcJuy37Qz3ThdCMaxmgLfvDKdiGQRplmvq5qTc9qO6 TZ9qKLuCddegMVhjga0NtiobjKg6PLEnRxgL5zz2pWtyvjq8DkTzGExi8F0TOEbt1VS6 SJKCKSKuxisY94sDLSnjBFZ6CbVf/iccVkgqkyJ7lzTDwyQhjcj4kJaaXQG0RrvX7aK+ b7erNw/H0xOuyW7QTbpa3hysAQfeGDAJgBpVDhlL44yO95aoq/iZVA0b7slo6i+cRV39 d+uQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=VMVJWBi5; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l76-v6si1579857pga.120.2018.06.20.19.04.31; Wed, 20 Jun 2018 19:04:46 -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; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=VMVJWBi5; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754295AbeFUCDv (ORCPT + 99 others); Wed, 20 Jun 2018 22:03:51 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:35490 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754186AbeFUCDu (ORCPT ); Wed, 20 Jun 2018 22:03:50 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w5L2041D033761 for ; Thu, 21 Jun 2018 02:03:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=corp-2017-10-26; bh=bPDabLFm/GD1lN7nSnmXAAMn5M+wEK6RlHiUeWSevoE=; b=VMVJWBi5KGmybqUU23mC/e/MjKSlc43zfRbnpb5MZ4k+PQnzojI7zSaAscTjqsb3FAmr yLdCFdG+RB2rlDeBuIIO1fnDy5ctyT1AogWFndkN+dKCI9V2qPNsQ5U6X3j4POY4onFW 1crjajgOsU+yL1yNO0HRFmGyS2m1mtQAWixRabZaS8/WRCn0t/cy42nQ5FJlLoriqni0 vgIAkRpWkYw4qAOesR67VtBzO6UEKWocKMNhtaqkMVBTBWQyfUEqJiMh2D0HXgtA2u8L Pbbbd1Xozja/SHWqcTde9BP9txxpA+vZLLJbR4jiN8C44nYhxtJd6EiI8FhxQ5bg8PBF vw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2jmtgwxu2b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 21 Jun 2018 02:03:49 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w5L23lHX031304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 21 Jun 2018 02:03:47 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w5L23ln6025936 for ; Thu, 21 Jun 2018 02:03:47 GMT Received: from mail-ot0-f171.google.com (/74.125.82.171) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 Jun 2018 19:03:47 -0700 Received: by mail-ot0-f171.google.com with SMTP id q17-v6so1781727otg.2 for ; Wed, 20 Jun 2018 19:03:47 -0700 (PDT) X-Gm-Message-State: APt69E1k/9DPxEJu2i4yI8zrteZs6GutlaWuDm5lRJJPfrjcmdbsZx57 BlzULUoKtK17erdvwuxqX5nrdd6oMLH8c9+SgvY= X-Received: by 2002:a9d:2010:: with SMTP id n16-v6mr13551535ota.275.1529546627039; Wed, 20 Jun 2018 19:03:47 -0700 (PDT) MIME-Version: 1.0 References: <20180601125321.30652-1-osalvador@techadventures.net> <20180601125321.30652-3-osalvador@techadventures.net> In-Reply-To: <20180601125321.30652-3-osalvador@techadventures.net> From: Pavel Tatashin Date: Wed, 20 Jun 2018 22:03:11 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/4] mm/memory_hotplug: Call register_mem_sect_under_node To: osalvador@techadventures.net Cc: Andrew Morton , Michal Hocko , Vlastimil Babka , Linux Memory Management List , LKML , osalvador@suse.de Content-Type: text/plain; charset="UTF-8" X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8930 signatures=668702 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=3 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=926 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806210020 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 1, 2018 at 8:54 AM wrote: > > 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. Indeed. > > 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(). Agree, this makes the code simpler. Please remove: > +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); Merge the above comment with: > + /* we online node here. we can't roll back from here. */ And replace all: > + if (ret) > + goto register_fail; With: BUG_ON(ret); With the above addressed: Reviewed-by: Pavel Tatashin