>>> + release_mem_region(range.start, range_len(&range)); >> >> remove_memory() does a release_mem_region_adjustable(). Don't you >> actually want to release the *unaligned* region you requested? >> > Isn't it what we're doing here? > (The release_mem_region_adjustable() is using the same > dax_kmem-aligned range and there's no split/adjust) Oh, I think I was messing up things (there is just too much going on in this patch). Right, request_mem_region() and add_memory_driver_managed() are - and were - called with the exact same range. That would have been clearer if the patch would simply use range.start and range_len(&range) for both calls (similar in the original code). So, also the release calls have to use the same range. Agreed. > > Meaning right now (+ parent marked as !BUSY), and if I am understanding > this correctly: > > request_mem_region(range.start, range_len) > __request_region(iomem_res, range.start, range_len) -> alloc @parent > add_memory_driver_managed(parent.start, resource_size(parent)) > __request_region(parent.start, resource_size(parent)) -> alloc @child > > [...] > > remove_memory(range.start, range_len) > request_mem_region_adjustable(range.start, range_len) > __release_region(range.start, range_len) -> remove @child > > release_mem_region(range.start, range_len) > __release_region(range.start, range_len) -> doesn't remove @parent because !BUSY? > > The add/removal of this relies on !BUSY. But now I am wondering if the parent remaining > unreleased is deliberate even on CONFIG_MEMORY_HOTREMOVE=y. Interesting, I can only tell that virtio-mem expects that remove_memory() won't remove the parent resource (which is !BUSY). So it relies on the existing functionality. I do wonder how walk_system_ram_range() behaves if both the parent and the child are BUSY. Looking at it, I think it will detect the parent and skip to the next range (without visiting the child) - which is not what we want. We could set the parent to BUSY just before doing the release_mem_region() call, but that feels like a hack. Maybe it's just easier to keep dax_kmem_res around ... -- Thanks, David / dhildenb _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
