Re: [PATCH v3 04/15] mm: update print_bad_page_map() to show anonymous page index

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Thu, Aug 06, 2026 at 05:54:41PM +0100, Matthew Wilcox wrote:
> On Wed, Aug 05, 2026 at 10:01:43AM +0100, Lorenzo Stoakes (ARM) wrote:
> > On Wed, Aug 05, 2026 at 04:30:18AM -0400, Gregory Price wrote:
> > > Yeah just an F/A in the print I suppose.  Sorry if that was unclear.
> > >
> > > If it saves someone the head-scratch of whether some bug is because it's
> > > "file" or "true anon", given the ambiguity here, seems like maybe useful
> > > debug information.
> >
> > Yeah will do on respin I think actually!
> >
> > I do think not providing that could result in some confusion like 'hm I
> > thought this was file-backed'.
>
> not sure it would.  Look at the whole thing:
>
>         pr_alert("BUG: Bad page map in process %s  %s:%08llx", current->comm,
>                  pgtable_level_to_str(level), entry);
>         __print_bad_page_map_pgtable(vma->vm_mm, addr);
>         if (page)
>                 dump_page(page, "bad page map");
>         pr_alert("addr:%px vm_flags:%08lx anon_vma:%px mapping:%px index:%lx\n",
>                  (void *)addr, vma->vm_flags, vma->anon_vma, mapping, index);
>         pr_alert("file:%pD fault:%ps mmap:%ps mmap_prepare: %ps read_folio:%ps\n",
>                  vma->vm_file,
>                  vma->vm_ops ? vma->vm_ops->fault : NULL,
>                  vma->vm_file ? vma->vm_file->f_op->mmap : NULL,
>                  vma->vm_file ? vma->vm_file->f_op->mmap_prepare : NULL,
>                  mapping ? mapping->a_ops->read_folio : NULL);
>
> even if we don't have 'page' and thus dump_page() won't tell us
> anything, we look at mapping (NULL means true-anon, non-NULL means
> file, possibly COW).

Ohhhh ok. But you still can't tell whether what's actually mapped in a
MAP_PRIVATE file-backed mapping.

So I still think giving separate anon and file indexes is useful for debugging
purposes in that case because you might be debugging an rmap thing and the
ranges of linear indexes might be handy.

>
> > (We've made our lives hard with varying definitions of 'anon'
> > also... [shmem being 'anon in page cache' is especially lol] so it's
> > already confusing but there we go :)
>
> Woah, woah, woah.  Do *not* think of shmem as being anon-in-page-cache.
> shmem is a filesystem that happens to use swap to store its backing
> file.  I dislike a number of things about how it's implemented, but
> describing it as anon-in-page-cache is furthering the confusion.

I am not sure 'file system that happens to use swap to back it' is that much
clearer ;)

But that _at least_ uses different terminology and swap-backed is pretty clear.

But :)

Functionally it's PG_swapbacked and !folio_test_anon() and nothing calls
it anon, except... well reclaim! Which gates on folio_test_swapbacked() for the
'anon' LRU and refers to it as anon throughout vmscan.c...

My point here was we made our lives difficult with naming and yeah we do. We so
so do.

--
Cheers, Lorenzo