All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "Michal Hocko" <mhocko@suse.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Takashi Iwai" <tiwai@suse.de>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Linux MM" <linux-mm@kvack.org>,
	"Yaowei Bai" <baiyaowei@cmss.chinamobile.com>,
	"Ross Zwisler" <zwisler@kernel.org>,
	"Sasha Levin" <sashal@kernel.org>,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	"James Morris" <jmorris@namei.org>,
	"Huang, Ying" <ying.huang@intel.com>,
	"Borislav Petkov" <bp@suse.de>,
	"Tom Lendacky" <thomas.lendacky@amd.com>,
	"Pavel Tatashin" <pasha.tatashin@soleen.com>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Fengguang Wu" <fengguang.wu@intel.com>
Subject: Re: [v5 2/3] mm/hotplug: make remove_memory() interface useable
Date: Mon, 6 May 2019 11:04:01 -0700	[thread overview]
Message-ID: <cf793443-c14a-a1e0-856e-15e416c7f874@intel.com> (raw)
In-Reply-To: <CAPcyv4greisKBSorzQWebcVOf2AqUH6DwbvNKMW0MQ5bCwYZrw@mail.gmail.com>

On 5/6/19 11:01 AM, Dan Williams wrote:
>>> +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.
> Please WARN() instead of BUG() because failing to remove memory should
> not be system fatal.

That is my preference as well.  But, the existing code BUG()s, so I'm
OK-ish with this staying for the moment until we have a better handle on
what all the callers do if this fails.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "Pavel Tatashin" <pasha.tatashin@soleen.com>,
	"James Morris" <jmorris@namei.org>,
	"Sasha Levin" <sashal@kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Linux MM" <linux-mm@kvack.org>,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Michal Hocko" <mhocko@suse.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Keith Busch" <keith.busch@intel.com>,
	"Vishal L Verma" <vishal.l.verma@intel.com>,
	"Dave Jiang" <dave.jiang@intel.com>,
	"Ross Zwisler" <zwisler@kernel.org>,
	"Tom Lendacky" <thomas.lendacky@amd.com>,
	"Huang, Ying" <ying.huang@intel.com>,
	"Fengguang Wu" <fengguang.wu@intel.com>,
	"Borislav Petkov" <bp@suse.de>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Yaowei Bai" <baiyaowei@cmss.chinamobile.com>,
	"Takashi Iwai" <tiwai@suse.de>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"David Hildenbrand" <david@redhat.com>
Subject: Re: [v5 2/3] mm/hotplug: make remove_memory() interface useable
Date: Mon, 6 May 2019 11:04:01 -0700	[thread overview]
Message-ID: <cf793443-c14a-a1e0-856e-15e416c7f874@intel.com> (raw)
In-Reply-To: <CAPcyv4greisKBSorzQWebcVOf2AqUH6DwbvNKMW0MQ5bCwYZrw@mail.gmail.com>

On 5/6/19 11:01 AM, Dan Williams wrote:
>>> +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.
> Please WARN() instead of BUG() because failing to remove memory should
> not be system fatal.

That is my preference as well.  But, the existing code BUG()s, so I'm
OK-ish with this staying for the moment until we have a better handle on
what all the callers do if this fails.

  reply	other threads:[~2019-05-06 18:04 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-02 18:43 [v5 0/3] "Hotremove" persistent memory Pavel Tatashin
2019-05-02 18:43 ` Pavel Tatashin
2019-05-02 18:43 ` [v5 1/3] device-dax: fix memory and resource leak if hotplug fails Pavel Tatashin
2019-05-02 18:43   ` Pavel Tatashin
2019-05-02 18:43 ` [v5 2/3] mm/hotplug: make remove_memory() interface useable Pavel Tatashin
2019-05-02 18:43   ` Pavel Tatashin
2019-05-03 10:06   ` David Hildenbrand
2019-05-03 10:06     ` David Hildenbrand
2019-05-06 17:57   ` Dave Hansen
2019-05-06 17:57     ` Dave Hansen
2019-05-06 18:01     ` Dan Williams
2019-05-06 18:01       ` Dan Williams
2019-05-06 18:04       ` Dave Hansen [this message]
2019-05-06 18:04         ` Dave Hansen
2019-05-06 18:18         ` Pavel Tatashin
2019-05-06 18:18           ` Pavel Tatashin
2019-05-17 18:10       ` Pavel Tatashin
2019-05-06 18:13     ` Pavel Tatashin
2019-05-02 18:43 ` [v5 3/3] device-dax: "Hotremove" persistent memory that is used like normal RAM Pavel Tatashin
2019-05-02 18:43   ` Pavel Tatashin
2019-05-02 20:50 ` [v5 0/3] "Hotremove" persistent memory Verma, Vishal L
2019-05-02 20:50   ` Verma, Vishal L
2019-05-02 21:44   ` Pavel Tatashin
2019-05-02 21:44     ` Pavel Tatashin
2019-05-02 21:44     ` Pavel Tatashin
2019-05-02 22:29     ` Verma, Vishal L
2019-05-02 22:29       ` Verma, Vishal L
2019-05-02 22:36       ` Pavel Tatashin
2019-05-02 22:36         ` Pavel Tatashin
2019-05-03 21:48         ` Verma, Vishal L
2019-05-15 18:11   ` Pavel Tatashin
2019-05-15 18:11     ` Pavel Tatashin
2019-05-15 18:11     ` Pavel Tatashin
2019-05-16  0:42     ` Dan Williams
2019-05-16  0:42       ` Dan Williams
2019-05-16  0:42       ` Dan Williams
2019-05-16  7:10       ` David Hildenbrand
2019-05-16  7:10         ` David Hildenbrand
2019-05-17 14:09       ` Pavel Tatashin
2019-05-17 14:09         ` Pavel Tatashin
2019-05-17 14:09         ` Pavel Tatashin
2019-05-20  7:57         ` David Hildenbrand
2019-05-20  7:57           ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cf793443-c14a-a1e0-856e-15e416c7f874@intel.com \
    --to=dave.hansen@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=baiyaowei@cmss.chinamobile.com \
    --cc=bhelgaas@google.com \
    --cc=bp@suse.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=fengguang.wu@intel.com \
    --cc=jglisse@redhat.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=mhocko@suse.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=sashal@kernel.org \
    --cc=thomas.lendacky@amd.com \
    --cc=tiwai@suse.de \
    --cc=ying.huang@intel.com \
    --cc=zwisler@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.