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

On Wed, Aug 05, 2026 at 04:30:18AM -0400, Gregory Price wrote:
> On Mon, Aug 03, 2026 at 11:19:17AM +0100, Lorenzo Stoakes (ARM) wrote:
> > On Mon, Aug 03, 2026 at 11:39:11AM +0200, David Hildenbrand (Arm) wrote:
> > > On 7/30/26 08:32, Gregory Price wrote:
> > > > On Wed, Jul 29, 2026 at 05:48:39PM +0100, Lorenzo Stoakes (ARM) wrote:
> > > >> This is potentially useful debugging information and matches the existing
> > > >> page offset provided.
> > > >>
> > > >> Use the raw __linear_anon_page_index() function so as to always output this
> > > >> value regardless of whether the mapping is file-backed or not.
> > > >>
> > > >
> > > > Begs the question whether we should mark the value based on whether
> > > > it is file backed or not, but i suppose you can gleen that from the
> > > > other printed values (anon_mem, mapping, vm_ops, etc).
> > >
> > > You mean something anon_pgoff_t or what did you have in mind?
> >
> > I suspect he means e.g. adding a (A) suffix or something? Like page offset xxx
> > (F) or yyy (A) I guess?
> >
>
> 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'.

(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 :)

I will add a comment explaining things so if anybody still wonders what's
going on they can see what's up in the code.

>
> ~Gregory

--
Cheers, Lorenzo