linux-kernel - Re: [PATCH 0/2] introduce pagetable_alloc

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <DF0NWLWKRKYI.3PLY78UGGG2PD@google.com>
Date: Wed, 17 Dec 2025 17:19:27 +0000
From: Brendan Jackman <jackmanb@...gle.com>
To: Vlastimil Babka <vbabka@...e.cz>, Brendan Jackman <jackmanb@...gle.com>, 
	Yeoreum Yun <yeoreum.yun@....com>, Ryan Roberts <ryan.roberts@....com>
Cc: <akpm@...ux-foundation.org>, <david@...nel.org>, 
	<lorenzo.stoakes@...cle.com>, <Liam.Howlett@...cle.com>, <rppt@...nel.org>, 
	<surenb@...gle.com>, <mhocko@...e.com>, <ast@...nel.org>, 
	<daniel@...earbox.net>, <andrii@...nel.org>, <martin.lau@...ux.dev>, 
	<eddyz87@...il.com>, <song@...nel.org>, <yonghong.song@...ux.dev>, 
	<john.fastabend@...il.com>, <kpsingh@...nel.org>, <sdf@...ichev.me>, 
	<haoluo@...gle.com>, <jolsa@...nel.org>, <hannes@...xchg.org>, 
	<ziy@...dia.com>, <bigeasy@...utronix.de>, <clrkwllms@...nel.org>, 
	<rostedt@...dmis.org>, <catalin.marinas@....com>, <will@...nel.org>, 
	<kevin.brodsky@....com>, <dev.jain@....com>, <yang@...amperecomputing.com>, 
	<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>, <bpf@...r.kernel.org>, 
	<linux-rt-devel@...ts.linux.dev>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 0/2] introduce pagetable_alloc_nolock()

>> From 4c6b4d4cb08aee9559d02a348b9ecf799142c96f Mon Sep 17 00:00:00 2001
>> From: Brendan Jackman <jackmanb@...gle.com>
>> Date: Wed, 17 Dec 2025 13:26:28 +0000
>> Subject: [PATCH] mm: clarify GFP_ATOMIC/GFP_NOWAIT doc-comment
>> 
>> The current description of contexts where it's invalid to make
>> GFP_ATOMIC and GFP_NOWAIT calls is rather vague.
>> 
>> Replace this with a direct description of the actual contexts of concern
>> and refer to the RT docs where this is explained more discursively.
>> 
>> While rejigging this prose, also move the documentation of GFP_NOWAIT to
>> the GFP_NOWAIT section.
>
> There doesn't seem to be any move?

This is referring to [0] and [1].

>> diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
>> index 3de43b12209ee..07a378542caf2 100644
>> --- a/include/linux/gfp_types.h
>> +++ b/include/linux/gfp_types.h
>> @@ -309,8 +309,10 @@ enum {
>>   *
>>   * %GFP_ATOMIC users can not sleep and need the allocation to succeed. A lower
>>   * watermark is applied to allow access to "atomic reserves".
>> - * The current implementation doesn't support NMI and few other strict
>> - * non-preemptive contexts (e.g. raw_spin_lock). The same applies to %GFP_NOWAIT.
[0]                                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> + * The current implementation doesn't support NMI, nor contexts that disable
>> + * preemption under PREEMPT_RT. This includes raw_spin_lock() and plain
>> + * preempt_disable() - see Documentation/core-api/real-time/differences.rst for
>> + * more info.
>
> Can we reference the "Memory allocation" section directly?

Yeah good point. I will send this as a standalone [PATCH] mail tomorrow.

>>   *
>>   * %GFP_KERNEL is typical for kernel-internal allocations. The caller requires
>>   * %ZONE_NORMAL or a lower zone for direct access but can direct reclaim.
>> @@ -321,6 +323,7 @@ enum {
>>   * %GFP_NOWAIT is for kernel allocations that should not stall for direct
>>   * reclaim, start physical IO or use any filesystem callback.  It is very
>>   * likely to fail to allocate memory, even for very small allocations.
>> + * The same restrictions on calling contexts apply as for %GFP_ATOMIC.
[1]     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^