Hi all, On Sun, 01 Nov 2026 19:58:21 +1100 Aveline Noir wrote:
> Oh, I missed that. I'll try to fix it. While working on this, I found that the fix reaches well beyond mm/hmm.c and would likely need rework in several subsystems, so I'd like to hear your views before going further. v1 shouldn't be applied as is. amdkfd holds svms->lock and prange->migrate_mutex across hmm_range_fault(), and svm_migrate_to_ram() needs both, so it can't migrate the page for the validating task. Migrating under those locks can deadlock, since do_swap_page() waits for the device page lock, which a concurrent CPU fault can hold while waiting for svms->lock. From reading the code, amdkfd also maps such read-only pages writable today, as it takes GPU write permission from the VMA rather than from HMM_PFN_WRITE, so GPU writes after fork() would be visible to the child. I haven't been able to confirm this on hardware. One option I tried is an opt-in HMM flag that returns -EDEADLK and the page address instead of faulting, so amdkfd can drop its locks, fault the page and validate again. It works with test_hmm, but the amdkfd side grew to about 550 lines across the GPU fault handler, the restore worker and svm_range_set_attr(), and is only compile-tested. Read-only entries also come from NUMA hinting scans and mprotect(), so pages that aren't shared would be moved out of VRAM too, and Xe and nouveau would see their pages migrated in the same cases. Would you prefer an opt-in interface like this, a change to the amdkfd locking so that migrate_to_ram() can run during validation, or something else? I can post the amdkfd part as an RFC if that helps. I also found a few smaller related issues, and I'll send fixes for them separately. Thanks, Aveline Noir
