From: Gregory Price <gourry@gourry.net>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: linux-mm@kvack.org, nvdimm@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org,
driver-core@lists.linux.dev, linux-kselftest@vger.kernel.org,
kernel-team@meta.com, osalvador@suse.de,
gregkh@linuxfoundation.org, rafael@kernel.org, dakr@kernel.org,
djbw@kernel.org, vishal.l.verma@intel.com, dave.jiang@intel.com,
akpm@linux-foundation.org, ljs@kernel.org, liam@infradead.org,
vbabka@kernel.org, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, shuah@kernel.org, alison.schofield@intel.com,
Smita.KoralahalliChannabasappa@amd.com, ira.weiny@intel.com,
apopple@nvidia.com
Subject: Re: [PATCH v5 5/9] mm/memory_hotplug: offline_and_remove_memory_ranges()
Date: Thu, 25 Jun 2026 09:51:42 -0400 [thread overview]
Message-ID: <aj0ybgV7n0pqXF0b@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <d48feca1-0203-43ff-bd66-6243291a51ba@kernel.org>
On Thu, Jun 25, 2026 at 09:22:01AM +0200, David Hildenbrand (Arm) wrote:
> On 6/24/26 16:57, Gregory Price wrote:
> > extern int offline_and_remove_memory(u64 start, u64 size);
> > +int offline_and_remove_memory_ranges(const struct range *ranges, int nr_ranges);
> >
> > #else
> > static inline void try_offline_node(int nid) {}
> > @@ -283,6 +284,12 @@ static inline int remove_memory(u64 start, u64 size)
> > }
> >
> > static inline void __remove_memory(u64 start, u64 size) {}
> > +
> > +static inline int offline_and_remove_memory_ranges(const struct range *ranges,
> > + int nr_ranges)
>
> Best to use "unsigned int" right from the start and use two tabs to indent.
>
ack, ack. need to reprogram my brain to two-indent style, i keep doing
this reflexively.
> > +int offline_and_remove_memory_ranges(const struct range *ranges, int nr_ranges)
> > +{
> > + unsigned long mb_total = 0;
> > uint8_t *online_types, *tmp;
> > - int rc;
> > + int i, rc = 0;
> >
> > - if (!IS_ALIGNED(start, memory_block_size_bytes()) ||
> > - !IS_ALIGNED(size, memory_block_size_bytes()) || !size)
> > + if (!ranges || nr_ranges <= 0)
>
> With "unsigned int" this will be !nr_ranges.
>
> Wondering whether we would WARN_ON_ONCE() here.
>
Seems reasonable. Do we normally WARN when callers send dumb arguments?
Seems like sending -EINVAL is sufficient?
> > - online_types = kmalloc_array(mb_count, sizeof(*online_types),
> > + online_types = kmalloc_array(mb_total, sizeof(*online_types),
> > GFP_KERNEL);
>
> Is "mb_total" really more expressive than "mb_count"?
>
No, this was mostly my way ok keeping try of what was being moved around
while working it. I will change it back.
> > /*
> > - * In case we succeeded to offline all memory, remove it.
> > - * This cannot fail as it cannot get onlined in the meantime.
> > + * Phase 2: Remove each range. This essentially cannot fail as we hold
> > + * the hotplug lock . WARN if that assumption is ever broken.
> > */
> > if (!rc) {
> > - rc = try_remove_memory(start, size);
> > - if (rc)
> > - pr_err("%s: Failed to remove memory: %d", __func__, rc);
> > + for (i = 0; i < nr_ranges; i++) {
> > + rc = try_remove_memory(ranges[i].start,
> > + range_len(&ranges[i]));
> > + if (WARN_ON_ONCE(rc)) {
> > + pr_err("%s: Failed to remove memory: %d",
> > + __func__, rc);
> > + break;
>
> Do we really want to break? I'd say, just warn and continue, and fake rc == 0.
> Something is seriously messed up already, and we partially removed memory. There
> is no clean rollback possible.
>
> Similar to __remove_memory(), ignoring the error because it offlined it already.
>
This seems reasonable, will change to warn and continue + return error.
Sashiko actually pointed out there there's a corner condition here with
offline rollback, so i needed to tweak this chunk anyway.
~Gregory
next prev parent reply other threads:[~2026-06-25 13:51 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-24 14:57 [PATCH v5 0/9] dax/kmem: atomic whole-device hotplug via sysfs Gregory Price
2026-06-24 14:57 ` [PATCH v5 1/9] mm/memory: add memory_block_aligned_range() helper Gregory Price
2026-06-24 15:08 ` sashiko-bot
2026-06-24 14:57 ` [PATCH v5 2/9] mm/memory_hotplug: pass online_type to online_memory_block() via arg Gregory Price
2026-06-24 16:28 ` Gupta, Pankaj
2026-06-24 14:57 ` [PATCH v5 3/9] mm/memory_hotplug: export mhp_get_default_online_type Gregory Price
2026-06-24 14:57 ` [PATCH v5 4/9] mm/memory_hotplug: add __add_memory_driver_managed() with online_type arg Gregory Price
2026-06-24 16:41 ` Gupta, Pankaj
2026-06-24 14:57 ` [PATCH v5 5/9] mm/memory_hotplug: offline_and_remove_memory_ranges() Gregory Price
2026-06-24 15:11 ` sashiko-bot
2026-06-25 7:22 ` David Hildenbrand (Arm)
2026-06-25 13:51 ` Gregory Price [this message]
2026-06-25 14:57 ` David Hildenbrand (Arm)
2026-06-24 14:57 ` [PATCH v5 6/9] dax: plumb hotplug online_type through dax Gregory Price
2026-06-24 15:12 ` sashiko-bot
2026-06-24 14:57 ` [PATCH v5 7/9] dax/kmem: extract hotplug/hotremove helper functions Gregory Price
2026-06-24 15:09 ` sashiko-bot
2026-06-24 14:57 ` [PATCH v5 8/9] dax/kmem: add sysfs interface for atomic whole-device hotplug Gregory Price
2026-06-24 15:11 ` sashiko-bot
2026-06-24 21:28 ` Gregory Price
2026-06-25 6:17 ` Hannes Reinecke
2026-06-25 6:43 ` Gregory Price
2026-06-25 7:40 ` David Hildenbrand (Arm)
2026-06-25 13:35 ` Gregory Price
2026-06-24 14:57 ` [PATCH v5 9/9] selftests/dax: add dax/kmem hotplug sysfs regression test Gregory Price
2026-06-24 15:12 ` sashiko-bot
2026-06-24 18:59 ` [PATCH v5 0/9] dax/kmem: atomic whole-device hotplug via sysfs Gregory Price
2026-06-25 7:41 ` David Hildenbrand (Arm)
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=aj0ybgV7n0pqXF0b@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=akpm@linux-foundation.org \
--cc=alison.schofield@intel.com \
--cc=apopple@nvidia.com \
--cc=dakr@kernel.org \
--cc=dave.jiang@intel.com \
--cc=david@kernel.org \
--cc=djbw@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=ira.weiny@intel.com \
--cc=kernel-team@meta.com \
--cc=liam@infradead.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=nvdimm@lists.linux.dev \
--cc=osalvador@suse.de \
--cc=rafael@kernel.org \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=vishal.l.verma@intel.com \
/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.