Re: [RFC V2 0/3] lib/vsprintf: Add support for pgtable entries

[David Hildenbrand (Arm)]

On 6/11/26 21:37, Matthew Wilcox wrote:
> On Thu, Jun 11, 2026 at 10:33:35PM +0300, Andy Shevchenko wrote:
>> On Thu, Jun 11, 2026 at 08:15:57PM +0100, Matthew Wilcox wrote:
>>>
>>> You didn't address my objection here:
>>>
>>> https://lore.kernel.org/linux-mm/aFQP8LzVMctf6XH5@xxxxxxxxxxxxxxxxxxxx/
>>>
>>> ie there is now no typechecking possible.  So you've made it more
>>> dangerous.  I reiterate my NACK to the concept, not to the implementation.
>>
>> But this is more of a global question, how do we check the validity of
>> the parameters of pointer extensions in the kernel? Does anybody go to
>> commit into GCC plugin or so for this job?
> 
> I agree that it's a global question that it would be great for somebody
> to answer.  But it's specifically a problem for this patchset because:
> 
>  - It's really easy to get confused about which page table level you're
>    working on.  And hugetlbfs deliberately increases that confusion.

Yeah ... so far I was assuming that for hugetlb, all relevant entries (what we
call a PTE although it isn't ....) would have to be the same size. I mean, at
least in the callers they are the same size (pte_t)

>  - Different levels of the page tables actually do have different sizes
>    on some architectures, so if you think you're looking at a pointer to a
>    64-bit quantity when it's really a pointer to a 32-bit quantity, things
>    Will Go Wrong (or vice-versa.  And some architctures are big-endian)

I see your point with the pass-by-pointer.

>  - But on x86-64, Everything Is Fine because all levels of the page table
>    are basically identical, so you'll never notice there's a problem.

I assume on most architectures.


Let's see if we can stop printing that information completely, so we can avoid
messing with this at all.

-- 
Cheers,

David