On Thu, Jul 09, 2026 at 04:07:31PM +0800, Richard Cheng wrote:
> > + if (dax_kmem_state_is_online(data->state)) {
> > + dev_warn(dev, "Hotplug regions stuck online until reboot\n");
> > + any_hotremove_failed = true;
> > + return;
>
> Hi Gregory,
>
> I suppose data->state is only updated when writing to the new daxX.Y/state
> file?
> If the blocks are offlined through the old per-block interface, data->state
> still says online and we will hit this early return.
> Everything is leaked and a later rebind fails -EBUSY.
>
> Current behavior is using remove_memory(), and it succeeds on offlined blocks
> and fails safely with -EBUSY on online ones, no offlining from unbind context
> either way.
>
> Your changelog state "on unbind fallback to legacy if still online", but the
> fallback only runs for data->state == MMOP_OFFLINE.
> Maybe drop this early return and just try dax_kmem_remove_ranges() here too?
>
Hm, I think you are right. When doing some testing I bounced between
tests which race with dax/state and block/state, and I missed the
obvious case of the whole device being offline but dax/state being stale.
I think this entire chunk actually just drops to:
dax_kmem_remove_ranges(dev_dax, data);
And the internal error catches the condition to the log.
Thanks! I will spin a new version next week.
~Gregory
