On 11/12/21 16:34, Jason Gunthorpe wrote:
> On Fri, Nov 12, 2021 at 04:08:24PM +0100, Joao Martins wrote:
>
>> diff --git a/drivers/dax/device.c b/drivers/dax/device.c
>> index a65c67ab5ee0..0c2ac97d397d 100644
>> +++ b/drivers/dax/device.c
>> @@ -192,6 +192,42 @@ static vm_fault_t __dev_dax_pud_fault(struct dev_dax *dev_dax,
>> }
>> #endif /* !CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
>>
>> +static void set_page_mapping(struct vm_fault *vmf, pfn_t pfn,
>> + unsigned long fault_size,
>> + struct address_space *f_mapping)
>> +{
>> + unsigned long i;
>> + pgoff_t pgoff;
>> +
>> + pgoff = linear_page_index(vmf->vma, ALIGN(vmf->address, fault_size));
>> +
>> + for (i = 0; i < fault_size / PAGE_SIZE; i++) {
>> + struct page *page;
>> +
>> + page = pfn_to_page(pfn_t_to_pfn(pfn) + i);
>> + if (page->mapping)
>> + continue;
>> + page->mapping = f_mapping;
>> + page->index = pgoff + i;
>> + }
>> +}
>> +
>> +static void set_compound_mapping(struct vm_fault *vmf, pfn_t pfn,
>> + unsigned long fault_size,
>> + struct address_space *f_mapping)
>> +{
>> + struct page *head;
>> +
>> + head = pfn_to_page(pfn_t_to_pfn(pfn));
>> + head = compound_head(head);
>> + if (head->mapping)
>> + return;
>> +
>> + head->mapping = f_mapping;
>> + head->index = linear_page_index(vmf->vma,
>> + ALIGN(vmf->address, fault_size));
>> +}
>
> Should this stuff be setup before doing vmf_insert_pfn_XX?
>
Interestingly filesystem-dax does this, but not device-dax.
set_page_mapping/set_compound_mapping() could be moved to before and then torn down
on @rc != VM_FAULT_NOPAGE (failure). I am not sure what's the benefit in this series..
besides the ordering (that you hinted below) ?
> In normal cases the page should be returned in the vmf and populated
> to the page tables by the core code after all this is done.
>
So I suppose by call sites examples as 'core code' is either hugetlbfs call to
__filemap_add_folio() (on hugetlbfs fault handler), shmem_add_to_page_cache() or
anon-equivalent.
