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

[David Hildenbrand (Arm)]

On 6/16/26 08:19, Hugh Dickins wrote:
> On Mon, 15 Jun 2026, David Hildenbrand (Arm) wrote:
>> On 6/12/26 23:26, Hugh Dickins wrote:
>>> ...
>>>
>>> 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.

Yes, I added them when we're processing PUD entries we'd also want
P4D entry + PUD entry.

This is one approach of having the printing be done mostly
manually, supporting 32, 64 and 128bit pte_val(). As raised by Ryan,
using local bufs to store the data to not involve printk.


I played with printing the byte stream manually, but didn't really like it.

Gave it a quick test and it seems to do its trick. I have the feeling that
this can be beautified a bit more.