Re: [RFC V2 3/3] mm: Replace pgtable entry prints with new format
From: Hugh Dickins
Date: Tue Jun 16 2026 - 02:20:14 EST
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