Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2771339yba; Mon, 6 May 2019 11:15:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqznrp3k8A4mUDQCGlijb2JcBnBT1PnP7HtqcJ/jwOzqoqeQQqQKjTyVYTdGx5+Uh8HbLp/o X-Received: by 2002:a17:902:4a:: with SMTP id 68mr19378467pla.235.1557166507910; Mon, 06 May 2019 11:15:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557166507; cv=none; d=google.com; s=arc-20160816; b=bMlJglNKXCejWL1AB0nnFv4QvzdS2UdpQWnENM+QgMTn70u7J/kUFvuA/Rs6mJvtzF YACRTquWQQsyTjUm8pnxpcfCDhxe+DLf5oFS0PKjkf42UOcMstljwehuKjqRuy2wRWYV Q1uQ4AoIbn55W3mgLSlWeguwoUkYKgIGyVfeSNiNGO7KVGdACe0oTLixZ70raSyVDIRn L0yW840m0qw9NkVJsH2kO3AGOLBokkqHbO45u2zRckG/ScM8D9OQShYGwvFHSaZd+mTb OIxx7BALDLCHW4aHSlFK7J+PNNhj8bY5B3oTl5HwN9BbRbv/qoUYglQNn6065sHWFs9V BAag== 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; bh=RF+CoYsepNrGbmmwc3BrcU2vzqm7V7BSod886VJiwv0=; b=sw8HX6lk2btH9f2tViZZTcCHyuutxyhgRm4c9GF8NxVxS3zmcxoRMCL0kU1uOEvg3W Ld8rg0e2caJ6Pqi4wlLcUUa6NZGuilwxWf1rgo98KqeKF66zGxMc4EgCucwXFZDkm98D P9e728vb+3HH1WGbq40pulk+9aepUmLcyJs3Ra3v/tHjIkm9w95iCFEtvRQKR4mO8uFC PuuUSwhN6Zc/uAcHPRwpwz5o8bHBlULyRrL0Y9AS7uQXMwlLxqkO6+l9Q7IGIQzCCxFB HRqPZ1OlPP8zyLUtQfkWUY0lObaRzGXz8yJlXFFu78QvlZyKFDl6gfrP8MctVJPTnUHU 5ZUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@soleen.com header.s=google header.b=iAd6JRjO; 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 y19si15498144plr.236.2019.05.06.11.14.51; Mon, 06 May 2019 11:15:07 -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=@soleen.com header.s=google header.b=iAd6JRjO; 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 S1726838AbfEFSNw (ORCPT + 99 others); Mon, 6 May 2019 14:13:52 -0400 Received: from mail-ed1-f66.google.com ([209.85.208.66]:36798 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726475AbfEFSNv (ORCPT ); Mon, 6 May 2019 14:13:51 -0400 Received: by mail-ed1-f66.google.com with SMTP id a8so16234415edx.3 for ; Mon, 06 May 2019 11:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RF+CoYsepNrGbmmwc3BrcU2vzqm7V7BSod886VJiwv0=; b=iAd6JRjOX6cXS5y0FNW2XJ6WvvRPKYhT/6IvHlZ2418SFSqTjnGNEmEfufAH09uPtF 49VkxpuxGKXyan9FEqMBuwApcLYmGUGixrOhtESpdlpABUMPZ7N8/UovTdziIhU88upK j4WE0SwVaZhfG1gNDqVLDDmhA75SiFdXba4UCXOJGgDdqfP1rS3rfmw/9d7SoRbMsGOM PO6LGgs5u/jSx2+y8jIHm9f8s43JUgyO4ndaBY82kSijPJK1XE4OCuAAhpxnGmqOtRBv IjlfDhj0TrBziM4BsbBli4RPSM49bmx3HScLhwrnqbvdsDMNlfsUYv5y2TfjyWFjkoIM dR8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RF+CoYsepNrGbmmwc3BrcU2vzqm7V7BSod886VJiwv0=; b=b53HlnqT8WLErUNRkmilPwgf5Z/EHxBmhwaMkerMDRo4AKi2bg+scGCr2f2ERG4Qo+ 9tfzIfdrWpGdY/Z+Dhaal7GPCk57fGmtdD64hU05xtH7XCdmx6pFnG6wqTwCU+RTONRo KuldljYL7Xa+BfpjZfjFvR47oTgghhl+QKdwfpDqSXEE7qVdIRTmMw8avcGJ7sy35mCA wq5+lC/P7HZB2OMv3pUUqOl767dOSbp9TshJ21jFi97hmcwxYw5d35KExu9GWAlidRRD KBrJolO55YRTkjnhu1jrvpauI0I1ckB0A9wIa9lRtpalVKp65ulkOZFj/GwMAy91gJkK ip9g== X-Gm-Message-State: APjAAAUPUrqr7BmFz9RXT36TnuxXkqu0/tP7Cg/hEJoFGM31BSPRCJfl Lr38IdnPQE4fOFC8jOZI+duX3m9UPQUMAtEtBtWXxg== X-Received: by 2002:a50:a951:: with SMTP id m17mr26721424edc.79.1557166429629; Mon, 06 May 2019 11:13:49 -0700 (PDT) MIME-Version: 1.0 References: <20190502184337.20538-1-pasha.tatashin@soleen.com> <20190502184337.20538-3-pasha.tatashin@soleen.com> In-Reply-To: From: Pavel Tatashin Date: Mon, 6 May 2019 14:13:38 -0400 Message-ID: Subject: Re: [v5 2/3] mm/hotplug: make remove_memory() interface useable To: Dave Hansen Cc: James Morris , Sasha Levin , LKML , linux-mm , linux-nvdimm , Andrew Morton , Michal Hocko , Dave Hansen , Dan Williams , Keith Busch , Vishal L Verma , Dave Jiang , Ross Zwisler , Tom Lendacky , "Huang, Ying" , Fengguang Wu , Borislav Petkov , Bjorn Helgaas , Yaowei Bai , Takashi Iwai , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , David Hildenbrand Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 6, 2019 at 1:57 PM Dave Hansen wrote: > > > -static inline void remove_memory(int nid, u64 start, u64 size) {} > > +static inline bool remove_memory(int nid, u64 start, u64 size) > > +{ > > + return -EBUSY; > > +} > > This seems like an appropriate place for a WARN_ONCE(), if someone > manages to call remove_memory() with hotplug disabled. > > BTW, I looked and can't think of a better errno, but -EBUSY probably > isn't the best error code, right? Same here, I looked and did not find any better then -EBUSY. Also, it is close to check_cpu_on_node() in the same file. > > > -void remove_memory(int nid, u64 start, u64 size) > > +/** > > + * remove_memory > > + * @nid: the node ID > > + * @start: physical address of the region to remove > > + * @size: size of the region to remove > > + * > > + * NOTE: The caller must call lock_device_hotplug() to serialize hotplug > > + * and online/offline operations before this call, as required by > > + * try_offline_node(). > > + */ > > +void __remove_memory(int nid, u64 start, u64 size) > > { > > + > > + /* > > + * trigger BUG() is some memory is not offlined prior to calling this > > + * function > > + */ > > + if (try_remove_memory(nid, start, size)) > > + BUG(); > > +} > > Could we call this remove_offline_memory()? That way, it makes _some_ > sense why we would BUG() if the memory isn't offline. Sure, I will rename this function. Thank you, Pasha