Hi Matthew, you actually got your understanding exactly inverted :) Amdgpu takes a look at page->mapping to make sure they are *not* coming from the call sequence starting with amdgpu_ttm_tt_set_user_pages() or be imported from another driver through DMA-buf etc... The only pages which are allowed to pass this check are the private driver allocated ones, see this code function amdgpu_ttm_tt_populate(): for (i = 0; i < ttm->num_pages; ++i) ttm->pages[i]->mapping = bdev->dev_mapping; So far that has been save since nobody else should be using the address space object from our drivers inode under /dev. But when you plan to remove page->mapping we probably have a problem here. Regards, Christian. Am 17.03.25 um 20:37 schrieb Matthew Wilcox: > We're close to removing page->mapping from the kernel, and I've run into > amdgpu's use of page->mapping (setting it to ->dev_mapping and comparing > it against ->dev_mapping). > > What I need to understand to know how to fix this properly is who > allocates these pages for what purpose? I've got this far: > > amdgpu_ttm_tt_set_user_pages() populates ttm->pages. > That's called from amdgpu_cs_parser_bos() which got e->userpages from > amdgpu_ttm_tt_get_user_pages(). > amdgpu_ttm_tt_get_user_pages() got them from > amdgpu_hmm_range_get_pages() > amdgpu_hmm_range_get_pages() gets them from calling hmm_pfn_to_page() > which ... could get pages from anywhere? > > But cleaarly they can't be _any_ pages because if they were anon or > file pages, overwriting page->mapping would blow up horribly today. > So they must be driver pages, but I can't see where they're allocated. > Is it ttm_pool_alloc_page()?
