On Thu, Oct 22, 2026 at 12:46:40PM -0400, Gregory Price (Meta) wrote:
> 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?
My concern isn't about 2 version of daxctl fighting. It's about
preserving the documented behavior for "daxctl offline-memory". And just
generally, if there is no need to change it, rather not change it.
>From the daxctl offline-memory man page:
If all blocks were already offline, print a message and return success
without actually doing anything.
It seems the benefit of atomic unplug is w "daxctl reconfigure-device"
path where memory needs to be removed before unbinding dax_kmem. Could
we limit atomic unplug to that path?
To be clear, I don't know if that (limiting) is doable and I also don't
know if any current user would care either way. I'm just defending the
documentated behavior (FWIW).
-- Alison
>
> > > + 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
>
