On Fri, Oct 03, 2025 at 06:16:14PM -0400, Felix Kuehling wrote: > It sounds like zone_device_page_init is just unsafe to use in > general.
It can only be used if you know the page is freed. > It assumes that pages have a 0 refcount. Yes > But I don't see a good way for drivers to guarantee that, because > they are not in control of when the page refcounts for their > zone-device pages get decremented. ?? Drivers are supposed to hoook pgmap->ops->page_free() and keep track. There is no way to write a driver without calling zone_device_page_init() as there is no other defined way to re-use a page that has been returned through page_free(). It is completely wrong to call get_page() on a 0 refcount folio, we don't have a debugging crash for this, but we really should. If you think the refcount could be 0 you have to use a try_get(). So this patch looks wrong to me, I see a page_free() implementation and this is the only call to zone_device_page_init(). If you remove it the driver is absolutely broken. I would expect migration should be writing to freed memory and zone_device_page_init() is the correct and only way to make freed memory usable again. Therefore, I expect the refcount to be 0 when svm_migrate_ram_to_vram() picks a dst. If it is not true, and you are tring to migrate to already allocated VRAM, then WTF? And if you really want to do that then yes you need to use get_page but you need a different path to handle already allocated vs page_free() called. get_page() MUST NOT be used to unfree page_free'd memory. The explanation in the commit doesn't really have enough detail: > 1. CPU page fault handler get vram page, migrate the vram page to > system page > 2. GPU page fault migrate to the vram page, set page refcount to 1 So why is the same vram page being used for both? For #1 the VRAM page is installed in a swap entry so it is has an elevated refcount. The implication is that #2 is targeting already allocated VRAM memory that is NOT FREE. Jason
