linux-kernel - Re: [RFC 1/2] lib/vsprintf: Add support for pte

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d5a86ef8-a58c-4abc-8312-08406c847edc@arm.com>
Date: Fri, 20 Jun 2025 13:42:53 +0530
From: Anshuman Khandual <anshuman.khandual@....com>
To: Matthew Wilcox <willy@...radead.org>
Cc: linux-mm@...ck.org, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 Rasmus Villemoes <linux@...musvillemoes.dk>,
 Sergey Senozhatsky <senozhatsky@...omium.org>, Petr Mladek
 <pmladek@...e.com>, Steven Rostedt <rostedt@...dmis.org>,
 Jonathan Corbet <corbet@....net>, Andrew Morton <akpm@...ux-foundation.org>,
 David Hildenbrand <david@...hat.com>, linux-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org
Subject: Re: [RFC 1/2] lib/vsprintf: Add support for pte_t

On 19/06/25 6:56 PM, Matthew Wilcox wrote:
> On Wed, Jun 18, 2025 at 09:42:34AM +0530, Anshuman Khandual wrote:
>> +++ b/mm/memory.c
>> @@ -522,9 +522,8 @@ static void print_bad_pte(struct vm_area_struct *vma, unsigned long addr,
>>  	mapping = vma->vm_file ? vma->vm_file->f_mapping : NULL;
>>  	index = linear_page_index(vma, addr);
>>  
>> -	pr_alert("BUG: Bad page map in process %s  pte:%08llx pmd:%08llx\n",
>> -		 current->comm,
>> -		 (long long)pte_val(pte), (long long)pmd_val(*pmd));
>> +	pr_alert("BUG: Bad page map in process %s  pte:%ppte pmd:%ppte\n",
>> +		 current->comm, &pte, pmd);
> 
> Unfortunately, the one example you've converted shows why this is a bad
> idea.  You're passing a pmd_t pointer to a function which is assuming a
> pte_t pointer.  And a pmd_t and a pte_t are sometimes different sizes!
> (eg sometimes one is 64 bit and the other 32 bit).

As discussed on a separate thread, this might be addressed via separate
printf formats for each page table level e.g %ppte, %ppmd, and %ppud etc. 

> 
> So no, NACK.
>