From: Dave Hansen <dave.hansen@intel.com> To: Pavel Tatashin <pasha.tatashin@soleen.com>, jmorris@namei.org, sashal@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org, akpm@linux-foundation.org, mhocko@suse.com, dave.hansen@linux.intel.com, dan.j.williams@intel.com, keith.busch@intel.com, vishal.l.verma@intel.com, dave.jiang@intel.com, zwisler@kernel.org, thomas.lendacky@amd.com, ying.huang@intel.com, fengguang.wu@intel.com, bp@suse.de, bhelgaas@google.com, baiyaowei@cmss.chinamobile.com, tiwai@suse.de, jglisse@redhat.com, david@redhat.com Subject: Re: [v5 2/3] mm/hotplug: make remove_memory() interface useable Date: Mon, 6 May 2019 10:57:28 -0700 [thread overview] Message-ID: <cac721ed-c404-19d1-71d1-37c66df9b2a8@intel.com> (raw) In-Reply-To: <20190502184337.20538-3-pasha.tatashin@soleen.com> > -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? > -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. _______________________________________________ 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: Pavel Tatashin <pasha.tatashin@soleen.com>, jmorris@namei.org, sashal@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org, akpm@linux-foundation.org, mhocko@suse.com, dave.hansen@linux.intel.com, dan.j.williams@intel.com, keith.busch@intel.com, vishal.l.verma@intel.com, dave.jiang@intel.com, zwisler@kernel.org, thomas.lendacky@amd.com, ying.huang@intel.com, fengguang.wu@intel.com, bp@suse.de, bhelgaas@google.com, baiyaowei@cmss.chinamobile.com, tiwai@suse.de, jglisse@redhat.com, david@redhat.com Subject: Re: [v5 2/3] mm/hotplug: make remove_memory() interface useable Date: Mon, 6 May 2019 10:57:28 -0700 [thread overview] Message-ID: <cac721ed-c404-19d1-71d1-37c66df9b2a8@intel.com> (raw) In-Reply-To: <20190502184337.20538-3-pasha.tatashin@soleen.com> > -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? > -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.
next prev parent reply other threads:[~2019-05-06 17:57 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 [this message] 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 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=cac721ed-c404-19d1-71d1-37c66df9b2a8@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=dave.jiang@intel.com \ --cc=david@redhat.com \ --cc=fengguang.wu@intel.com \ --cc=jglisse@redhat.com \ --cc=jmorris@namei.org \ --cc=keith.busch@intel.com \ --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=vishal.l.verma@intel.com \ --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: linkBe 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.