Re: [RFC V2 3/3] mm: Replace pgtable entry prints with new format

[Hugh Dickins <hughd@google.com>]

On Mon, 15 Jun 2026, David Hildenbrand (Arm) wrote:
> On 6/12/26 23:26, Hugh Dickins wrote:
> > On Fri, 12 Jun 2026, David Hildenbrand (Arm) wrote:
> > ...
> >>
> >> After some off-list discussion, I wonder if we can make our life easier.
> >>
> >> I think, even with your patch, there is still the case:
> >>
> >> pr_alert("BUG: Bad page map in process %s  %s:%08llx", current->comm,
> >> 	 pgtable_level_to_str(level), entry);
> >>
> >> Where we cast all entries to an "unsigned long" in the callers. We'd have to rework all
> >> that for 128bit entries either way (passing them in some struct instead).
> >>
> >> I really just extended what we used to do here in print_bad_pte() before commit ec63a44011d.
> >>
> >> Maybe we should just drop the "print the involved page table entries" thing?
> >>
> >> I mean, we do have the actual page, and we do have the address in the address space, which
> >> we all print.
> >>
> >> Not sure if the actual page table entries are that relevant?
> > 
> > The page table entry is BUGgily Bad: we want to see what it looks like
> > (sometimes, a sequence of bad page map entries may even show up as ASCII).
> 
> But is printing raw page table entries really what we want? I guess to detect
> "random corruption" it might help sometimes.

Yes, that's what it's for. What we really want is to understand what went
wrong: that's too much to ask of a printk, but it can give us a good clue.

> 
> And do we really need information about the full page table walk, or is the last
> level good enough?

Page table entry and pmd entry are good enough: higher levels got
added at some stage, but they are unlikely to be useful here.

Hugh