From: Dev Jain <dev.jain@arm.com>
To: Usama Arif <usamaarif642@gmail.com>,
akpm@linux-foundation.org, david@kernel.org
Cc: lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com,
vbabka@suse.cz, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, ryan.roberts@arm.com,
anshuman.khandual@arm.com, kirill@shutemov.name,
willy@infradead.org
Subject: Re: [PATCH] mm: map maximum pages possible in finish_fault
Date: Tue, 10 Feb 2026 18:59:15 +0530 [thread overview]
Message-ID: <a2cdcf67-ca27-4d8a-96e0-d5a677e7dbc6@arm.com> (raw)
In-Reply-To: <687c7173-31c9-457a-9900-68e7f38688ed@gmail.com>
On 07/02/26 11:38 pm, Usama Arif wrote:
>> @@ -5619,49 +5619,53 @@ vm_fault_t finish_fault(struct vm_fault *vmf)
>> nr_pages = folio_nr_pages(folio);
>>
>> /* Using per-page fault to maintain the uffd semantics */
>> - if (unlikely(userfaultfd_armed(vma)) || unlikely(needs_fallback)) {
>> + if (unlikely(userfaultfd_armed(vma)) || unlikely(single_page_fallback)) {
>> nr_pages = 1;
>> } else if (nr_pages > 1) {
>> - pgoff_t idx = folio_page_idx(folio, page);
>> - /* The page offset of vmf->address within the VMA. */
>> - pgoff_t vma_off = vmf->pgoff - vmf->vma->vm_pgoff;
>> - /* The index of the entry in the pagetable for fault page. */
>> - pgoff_t pte_off = pte_index(vmf->address);
>> +
>> + /* Ensure mapping stays within VMA and PMD boundaries */
>> + unsigned long pmd_boundary_start = ALIGN_DOWN(vmf->address, PMD_SIZE);
>> + unsigned long pmd_boundary_end = pmd_boundary_start + PMD_SIZE;
>> + unsigned long va_of_folio_start = vmf->address - ((vmf->pgoff - folio->index) * PAGE_SIZE);
>> + unsigned long va_of_folio_end = va_of_folio_start + nr_pages * PAGE_SIZE;
>> + unsigned long end_addr;
>
> Hello!
>
> Can va_of_folio_start underflow here? For e.g. if you MAP_FIXED at a very low address and
> vmf->pgoff is big.
>
>
> max3() would then pick this huge value as start_addr/
>
> I think the old code guarded against this explicitly below:
> if (unlikely(vma_off < idx || ...)) {
> nr_pages = 1;
> }
Indeed! Thanks for the spot, I'll fix this.
>
>> +
>> + start_addr = max3(vma->vm_start, pmd_boundary_start, va_of_folio_start);
>> + end_addr = min3(vma->vm_end, pmd_boundary_end, va_of_folio_end);
>>
>> /*
>> - * Fallback to per-page fault in case the folio size in page
>> - * cache beyond the VMA limits and PMD pagetable limits.
>> + * Do not allow to map with PTEs across i_size to preserve
>> + * SIGBUS semantics.
>> + *
>> + * Make an exception for shmem/tmpfs that for long time
>> + * intentionally mapped with PMDs across i_size.
>> */
>> - if (unlikely(vma_off < idx ||
>> - vma_off + (nr_pages - idx) > vma_pages(vma) ||
>> - pte_off < idx ||
>> - pte_off + (nr_pages - idx) > PTRS_PER_PTE)) {
>> - nr_pages = 1;
>> - } else {
>> - /* Now we can set mappings for the whole large folio. */
>> - addr = vmf->address - idx * PAGE_SIZE;
>> - page = &folio->page;
>> - }
>> + if (mapping && !shmem_mapping(mapping))
>> + end_addr = min(end_addr, va_of_folio_start + (file_end - folio->index) * PAGE_SIZE);
>> +
>> + nr_pages = (end_addr - start_addr) >> PAGE_SHIFT;
>> + page = folio_page(folio, (start_addr - va_of_folio_start) >> PAGE_SHIFT);
>> }
>>
>> vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd,
>> - addr, &vmf->ptl);
>> + start_addr, &vmf->ptl);
>> if (!vmf->pte)
>> return VM_FAULT_NOPAGE;
>>
>> /* Re-check under ptl */
>> if (nr_pages == 1 && unlikely(vmf_pte_changed(vmf))) {
>> - update_mmu_tlb(vma, addr, vmf->pte);
>> + update_mmu_tlb(vma, start_addr, vmf->pte);
>> ret = VM_FAULT_NOPAGE;
>> goto unlock;
>> } else if (nr_pages > 1 && !pte_range_none(vmf->pte, nr_pages)) {
>> - needs_fallback = true;
>> + single_page_fallback = true;
>> + try_pmd_mapping = false;
>> pte_unmap_unlock(vmf->pte, vmf->ptl);
>> goto fallback;
>> }
>>
>> folio_ref_add(folio, nr_pages - 1);
>> - set_pte_range(vmf, folio, page, nr_pages, addr);
>> + set_pte_range(vmf, folio, page, nr_pages, start_addr);
>> type = is_cow ? MM_ANONPAGES : mm_counter_file(folio);
>> add_mm_counter(vma->vm_mm, type, nr_pages);
>> ret = 0;
next prev parent reply other threads:[~2026-02-10 13:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-06 13:56 Dev Jain
2026-02-06 15:22 ` Matthew Wilcox
2026-02-10 13:28 ` Dev Jain
2026-02-10 13:39 ` Lorenzo Stoakes
2026-02-10 13:54 ` Dev Jain
2026-02-10 16:27 ` Matthew Wilcox
2026-02-06 19:27 ` [syzbot ci] " syzbot ci
2026-02-07 18:08 ` [PATCH] " Usama Arif
2026-02-10 13:29 ` Dev Jain [this message]
2026-02-11 11:33 ` David Hildenbrand (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a2cdcf67-ca27-4d8a-96e0-d5a677e7dbc6@arm.com \
--to=dev.jain@arm.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=david@kernel.org \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=surenb@google.com \
--cc=usamaarif642@gmail.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox