linux-kernel - Re: [PATCH 1/2] arm64/mm: Allow __create_pgd_mapping() to propagate pgtable

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: <f53dd685-4e05-4fd3-a49d-0074b69a8ce1@arm.com>
Date: Fri, 15 Aug 2025 14:12:03 +0200
From: Kevin Brodsky <kevin.brodsky@....com>
To: Dev Jain <dev.jain@....com>,
 Chaitanya S Prakash <chaitanyas.prakash@....com>,
 linux-arm-kernel@...ts.infradead.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Cc: Ryan Roberts <ryan.roberts@....com>,
 Yang Shi <yang@...amperecomputing.com>,
 Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
 Anshuman Khandual <anshuman.khandual@....com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Zhenhua Huang <quic_zhenhuah@...cinc.com>
Subject: Re: [PATCH 1/2] arm64/mm: Allow __create_pgd_mapping() to propagate
 pgtable_alloc() errors

On 15/08/2025 09:30, Dev Jain wrote:
>
> On 13/08/25 8:26 pm, Chaitanya S Prakash wrote:
>> [-------snip-------------]
>>   -static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
>> +static int __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
>>                    unsigned long virt, phys_addr_t size,
>>                    pgprot_t prot,
>>                    phys_addr_t (*pgtable_alloc)(enum pgtable_type),
>>                    int flags)
>>   {
>> +    int ret = 0;
>> +
>>       mutex_lock(&fixmap_lock);
>> -    __create_pgd_mapping_locked(pgdir, phys, virt, size, prot,
>> -                    pgtable_alloc, flags);
>> +    ret = __create_pgd_mapping_locked(pgdir, phys, virt, size, prot,
>> +                      pgtable_alloc, flags);
>>       mutex_unlock(&fixmap_lock);
>> +
>> +    return ret;
>> +}
>> +
>> +static void ___create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
>> +                  unsigned long virt, phys_addr_t size,
>> +                  pgprot_t prot,
>> +                  phys_addr_t (*pgtable_alloc)(enum pgtable_type),
>> +                  int flags)
>> +{
>> +    int ret = 0;
>> +
>> +    ret = __create_pgd_mapping(pgdir, phys, virt, size, prot,
>> pgtable_alloc,
>> +                   flags);
>> +    BUG_ON(ret);
>>   }
>
> A triple underscore calling a double underscore isn't natural to
> reason about.

Also not the most readable (easy to confuse the two).

> Since this is the function which must succeed, how does
> "must_create_pgd_mapping()"
> sound?

"must" isn't a prefix that is commonly used in that sense, not sure this
is very clear.

Another idea that comes to mind is early_create_pgd_mapping() - the
BUG_ON() being justified by the fact that early errors are not recoverable.

On a related note, it would be possible to return an error from
create_pgd_mapping() and create_mapping_noalloc() as their callers
already have error paths. That would be a bit cleaner but I don't know
if it's worth the hassle.

- Kevin