On 02.03.20 13:48, Michal Hocko wrote: > On Tue 25-02-20 15:27:28, David Hildenbrand wrote: >> On 25.02.20 15:11, Michal Hocko wrote: >>> On Thu 12-12-19 18:11:32, David Hildenbrand wrote: >>>> virtio-mem wants to offline and remove a memory block once it unplugged >>>> all subblocks (e.g., using alloc_contig_range()). Let's provide >>>> an interface to do that from a driver. virtio-mem already supports to >>>> offline partially unplugged memory blocks. Offlining a fully unplugged >>>> memory block will not require to migrate any pages. All unplugged >>>> subblocks are PageOffline() and have a reference count of 0 - so >>>> offlining code will simply skip them. >>>> >>>> All we need an interface to trigger the "offlining" and the removing in a >>>> single operation - to make sure the memory block cannot get onlined by >>>> user space again before it gets removed. >>> >>> Why does that matter? Is it really likely that the userspace would >>> interfere? What would be the scenario? >> >> I guess it's not that relevant after all (I think this comment dates >> back to the times where we didn't have try_remove_memory() and could >> actually BUG_ON() in remove_memory() if there would have been a race). >> Can drop that part. >> >>> >>> Or is still mostly about not requiring callers to open code this general >>> patter? >> >> From kernel module context, I cannot get access to the actual memory >> block device (find_memory_block()) and call the device_unregister(). >> >> Especially, also the device hotplug lock is not exported. So this is a >> clean helper function to be used from kernel module context. (e.g., also >> hyper-v showed interest for using that) > > Fair enough. > I'll send a v1 shortly, I rephrased the description to make this clear. Thanks! -- Thanks, David / dhildenb