Re: [syzbot] [mm?] WARNING in __folio_rmap_sanity_checks (2)

Hillf Danton
2025-01-11T01:02:01Z

On Fri, 10 Jan 2025 17:35:25 +0100 David Hildenbrand <david@redhat.com>
> On 31.12.24 09:41, Hillf Danton wrote:
> > On Fri, 27 Dec 2024 20:56:21 -0800
> >> syzbot has found a reproducer for the following issue on:
> >>
> >> HEAD commit: 8155b4ef3466 Add linux-next specific files for 20241220
> >> git tree: linux-next
> >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1652fadf980000
> >
> > #syz test
> >
> > --- x/mm/filemap.c
> > +++ y/mm/filemap.c
> > @@ -3636,6 +3636,10 @@ static vm_fault_t filemap_map_folio_rang
> > continue;
> > skip:
> > if (count) {
> > + for (unsigned int i = 0; i < count; i++) {
> > + if (page_folio(page + i) != folio)
> > + goto out;
> > + }
>
> IIRC, count <= nr_pages. Wouldn't that mean that we somehow pass in
> nr_pages that already exceeds the given folio+start?
>
> When I last looked at this, I was not able to spot the error in the
> caller :(
>
This is a debug patch at the first place, and this hunk overlaps with the
next one.
> > set_pte_range(vmf, folio, page, count, addr);
> > *rss += count;
> > folio_ref_add(folio, count);
> > @@ -3658,6 +3662,7 @@ skip:
> > ret = VM_FAULT_NOPAGE;
> > }
> >
> > +out:
> > vmf->pte = old_ptep;
> >
> > return ret;
> > @@ -3702,7 +3707,7 @@ vm_fault_t filemap_map_pages(struct vm_f
> > struct file *file = vma->vm_file;
> > struct address_space *mapping = file->f_mapping;
> > pgoff_t file_end, last_pgoff = start_pgoff;
> > - unsigned long addr;
> > + unsigned long addr, pmd_end;
> > XA_STATE(xas, &mapping->i_pages, start_pgoff);
> > struct folio *folio;
> > vm_fault_t ret = 0;
> > @@ -3731,6 +3736,12 @@ vm_fault_t filemap_map_pages(struct vm_f
> > if (end_pgoff > file_end)
> > end_pgoff = file_end;
> >
> > + /* make vmf->pte[x] valid */
> > + pmd_end = ALIGN(addr, PMD_SIZE);
> > + pmd_end = (pmd_end - addr) >> PAGE_SHIFT;
> > + if (end_pgoff - start_pgoff > pmd_end)
> > + end_pgoff = start_pgoff + pmd_end;
> > +
>
> do_fault_around() comments "This way it's easier to guarantee that we
> don't cross page table boundaries."
>
> It does some magic with PTRS_PER_PTE.
>
> You're diff here seems to indicate that this is not the case?
>
> But it's rather surprising that we see these issues pop up just now in
> -next.
>
Given double check [1], I am lean to thinking this is a simple OOB issue.

[1] https://lore.kernel.org/all/6774eca1.050a0220.25abdd.09b2.GAE@google.com/