On 2/3/2023 10:17 PM, Kirill A. Shutemov wrote:
> On Fri, Feb 03, 2023 at 09:16:33PM +0800, Yin Fengwei wrote:
>> @@ -3378,45 +3425,18 @@ vm_fault_t filemap_map_pages(struct vm_fault *vmf,
>> addr = vma->vm_start + ((start_pgoff - vma->vm_pgoff) << PAGE_SHIFT);
>> vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
>> do {
>> -again:
>> - page = folio_file_page(folio, xas.xa_index);
>> - if (PageHWPoison(page))
>> - goto unlock;
>> -
>> - if (mmap_miss > 0)
>> - mmap_miss--;
>> + unsigned long end;
>>
>> addr += (xas.xa_index - last_pgoff) << PAGE_SHIFT;
>> vmf->pte += xas.xa_index - last_pgoff;
>> last_pgoff = xas.xa_index;
>> + end = folio->index + folio_nr_pages(folio) - 1;
>> + nr_pages = min(end, end_pgoff) - xas.xa_index + 1;
>>
>> - /*
>> - * NOTE: If there're PTE markers, we'll leave them to be
>> - * handled in the specific fault path, and it'll prohibit the
>> - * fault-around logic.
>> - */
>> - if (!pte_none(*vmf->pte))
>> - goto unlock;
>> -
>> - /* We're about to handle the fault */
>> - if (vmf->address == addr)
>> - ret = VM_FAULT_NOPAGE;
>> + ret |= filemap_map_folio_range(vmf, folio,
>> + xas.xa_index - folio->index, addr, nr_pages);
>> + xas.xa_index = end;
>
> IIRC, end here can be beyond end_pgoff. Can it cause an issue? I don't see
> it, but just in case.
Yes. end can beyond end_pgoff. And it's fine because that will end the loop
and no access to xas.xa_index after that. But let me change the line to:
xas.xa_index += nr_pages;
to keep the same behavior as before in next version. Thanks.
Regards
Yin, Fengwei
>
>
