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: <7b2673cb-1f0e-4a5a-84e3-0ae10437308d@suse.cz>
Date: Thu, 18 Dec 2025 08:47:44 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: 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()

On 12/17/25 18:19, Brendan Jackman wrote:
>>> 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].

Oh I missed [0]. Thanks!

>>> 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]     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>