From: Gregory Price <gourry@gourry.net>
To: Hannes Reinecke <hare@suse.de>
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, david@kernel.org, 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 8/9] dax/kmem: add sysfs interface for atomic whole-device hotplug
Date: Thu, 25 Jun 2026 02:43:48 -0400 [thread overview]
Message-ID: <ajzOJPgV1acrUfr4@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <8e42587a-d614-4259-ae6b-5bca1479b425@suse.de>
>
> Why do we need to treat the 'unbind' call as a given thing?
> If we know that we cannot handle online memory during unbind,
> can't we just disallow unbind in that case?
No. Unbind is a violent operation - unbinds cannot fail, and a
straight, uncoordinated unbind is essentially a `--force` flag:
the admin accepts the risks.
To your point, the admin either does the nice thing are they
muck up the system.
But we should still try to do something sane to defend the kernel,
in this case we should try to prevent that task from becoming
deadlocked. The only way to do that is to leak the resources.
I'm making a small modification to this code to reinstate the
legacy behavior when "state!=UNPLUGGED".
~Gregory
next prev parent reply other threads:[~2026-06-25 6:43 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
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 [this message]
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=ajzOJPgV1acrUfr4@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=hare@suse.de \
--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.