Re: [PATCH 0/8] dax/kmem: atomic whole-device hotplug via sysfs

David Hildenbrand (Arm)
2026-04-13T19:40:59Z

On 4/13/26 21:38, Gregory Price wrote:
> On Mon, Apr 13, 2026 at 05:47:01PM +0200, David Hildenbrand (Arm) wrote:
>>
>> So, really only user space can try offlining the memory after requested
>> onlining succeeded.
>>
>> I don't think any udev rules do that? The usually only request to
>> online, which should be fine.
>>
>
> In the offline case the block will cease to exist after offlin/remove
> returns, so what should happen is the race on offline just fails and
> the stale object cleans itself up on the way out after failure.
>
> Userland temporarily sees a stale memory block but can't do anything
> with it because sync'd on hotplug lock.

Exactly.

>
>> So if a user does that manually, good for him. We just have to make sure
>> that stuff keeps working as expected.
>>
>
> Yeah the only catch is if a user does something dumb like
>
> cat block/state -> online_movable
> echo offline > block/state
> echo online > block/state
>
> But like... don't do that :]

Yes :)

>
> Udev won't ever offline-online-race like this, so it's not a real issue.
>
>> Or am I missing a case?
>>
>
> So yeah, I'm fairly confident this just works.
>
>>
>> I'll note that offline_and_remove_memory() can take a long time/forever
>> to succeed. User space can abort it by sending a critical signal.
>>
>> For example, if you do
>>
>> $ echo "unplugged" > magic_device_file
>>
>> And it hangs, user space can kill the "echo" command, sending a fatal
>> signal and making offline_and_remove_memory() fail.
>>
>> The question is, if you want to do your best to revert the other offline
>> operations and try re-adding/onlining what you already offlined.
>>
>> offline_and_remove_memory() handles that much nicer internally, as it
>> tries to revert offlining, and only removes once everything was offlined.
>>
>> I think I raised it previously, but you could add a
>> offline_and_remove_memory_ranges() that consumes multiple ranges, and
>> would do this for you under a single lock_device_hotplug().
>>
>
> I don't think this is a very large lift, just a slightly larger hotplug
> locking scope. But then - the per-range thing in this set should just
> work, so let me know if it's worth the extra churn.

Well, you can rather cleanly undo the operation if any offlining fails.
If that's not a requirement, then no need to change it!

--
Cheers,

David