On 2026-10-21 19:20 -0700, Alison Schofield wrote:
> On Fri, Oct 16, 2026 at 05:42:45PM -0400, Gregory Price (Meta) wrote:
> > + /*
> > + * Unplug atomically where supported, even if already offline, so
> > + * no agent can online blocks before a later unbind.
> > + */
> > + state = daxctl_dev_get_kmem_state(dev);
> > + unplug = state != DAXCTL_KMEM_UNKNOWN && state != DAXCTL_KMEM_UNPLUGGED;
> > +
>
> Hi Greg,
>
> I see you called this out in the cover letter, and that the kernel is
> deliberately combining offlining and removing memory to avoid the race
> before unbind.
>
> But, this does change the behavior of the command "daxctl offline-memory".
> Previously it left memory blocks present but offline and now it removes
> them entirely.
>
> Should offline-memory keep its existing behavior of leaving memory blocks
> offline, and use atomic unplug only when reconfiguring the device?
>
The kernel explicitly does not allow `echo offline > dax/state` because
this just creates the race we're trying to resolve.
I suppose my pushback is: why does it matter that daxctl offline-memory
changes in this way? If daxctl supports the atomic interface, it all just
works. It's a bit more work (additional hot-unplug) but if the memory is
already offline that's not that expensive.
The only scenario I could come up with is having two versions of daxctl
fight with each other (old - no awareness of dax/state, new - uses
dax/state) but is this a real concern?
> > + if (unplug) {
> > + rc = daxctl_dev_set_kmem_state(dev, DAXCTL_KMEM_UNPLUGGED);
> > + if (rc < 0 && num_on == 0) {
> > + /* already offline, unplug is best effort */
>
> When num_on == 0, another agent could online a block between the earlier
> check and the unplug and that memory would then be removed.
>
> I see this noted in the commit message. Is that worth documenting for
> users?
>
Yes that's intended, and yeah should probably update the docs.
~Gregory
--
~Gregory
