linux-kernel - Re: [PATCH 06/21] mm/page_alloc: add __GFP

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: <DG0CGGDZ2G7J.54SC3XV42CWW@google.com>
Date: Wed, 28 Jan 2026 15:57:07 +0000
From: Brendan Jackman <jackmanb@...gle.com>
To: Borislav Petkov <bp@...en8.de>, Brendan Jackman <jackmanb@...gle.com>
Cc: Dave Hansen <dave.hansen@...el.com>, Andy Lutomirski <luto@...nel.org>, 
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, "Liam R. Howlett" <Liam.Howlett@...cle.com>, 
	Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>, 
	Johannes Weiner <hannes@...xchg.org>, Zi Yan <ziy@...dia.com>, 
	Axel Rasmussen <axelrasmussen@...gle.com>, Yuanchu Xie <yuanchu@...gle.com>, 
	Roman Gushchin <roman.gushchin@...ux.dev>, <peterz@...radead.org>, 
	<dave.hansen@...ux.intel.com>, <mingo@...hat.com>, <tglx@...utronix.de>, 
	<akpm@...ux-foundation.org>, <david@...hat.com>, <derkling@...gle.com>, 
	<junaids@...gle.com>, <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>, 
	<reijiw@...gle.com>, <rientjes@...gle.com>, <rppt@...nel.org>, 
	<vbabka@...e.cz>, <x86@...nel.org>, <yosry.ahmed@...ux.dev>
Subject: Re: [PATCH 06/21] mm/page_alloc: add __GFP_SENSITIVE and always set it

On Wed Jan 28, 2026 at 3:38 PM UTC, Borislav Petkov wrote:
> On Thu, Oct 02, 2025 at 02:34:33PM +0000, Brendan Jackman wrote:
>> On Wed Oct 1, 2025 at 9:18 PM UTC, Dave Hansen wrote:
>> > On 9/24/25 07:59, Brendan Jackman wrote:
>> >> +#ifdef CONFIG_MITIGATION_ADDRESS_SPACE_ISOLATION
>> >> +#define ___GFP_SENSITIVE	BIT(___GFP_SENSITIVE_BIT)
>> >> +#else
>> >> +#define ___GFP_SENSITIVE 0
>> >> +#endif
>> >
>> > This is clearly one of the inflection points of the series.
>> >
>> > To go any farther with this approach, I think it's critical to get a few
>> > acks on this hunk specifically. Well, maybe not formal acked-by's, but
>> > at least _clear_ agreement from at least one of:
>> >
>> > 	MEMORY MANAGEMENT - PAGE ALLOCATOR
>> > 	M:      Andrew Morton <akpm@...ux-foundation.org>
>> > 	M:      Vlastimil Babka <vbabka@...e.cz>
>> >
>> > ... or this approach is dead in the water.
>> 
>> Yep, I agree. This is where the chicken-and-egg thing I mentioned in [0]
>> comes into play though...
>> 
>> [0] https://lore.kernel.org/all/DD7SCRK2OJI9.1EJ9GSEH9FHW2@google.com/
>
> Btw:
>
> ./include/linux/sockptr.h: In function ‘memdup_sockptr_noprof’:
> ./include/linux/gfp_types.h:306:41: error: ‘___GFP_SENSITIVE’ undeclared (first use in this function); did you mean ‘___GFP_SENSITIVE_BIT’?
>   306 | #define __GFP_SENSITIVE ((__force gfp_t)___GFP_SENSITIVE)
>       |                                         ^~~~~~~~~~~~~~~~
> ./include/linux/slab.h:1049:76: note: in definition of macro ‘kmalloc_node_track_caller_noprof’
>  1049 |         __kmalloc_node_track_caller_noprof(PASS_BUCKET_PARAMS(size, NULL), flags, node, caller)
>       |                                                                            ^~~~~
> ./include/linux/sockptr.h:126:19: note: in expansion of macro ‘kmalloc_track_caller_noprof’
>   126 |         void *p = kmalloc_track_caller_noprof(len, GFP_USER | __GFP_NOWARN);
>       |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/linux/gfp_types.h:390:43: note: in expansion of macro ‘__GFP_SENSITIVE’
>   390 |                          __GFP_HARDWALL | __GFP_SENSITIVE)
>       |                                           ^~~~~~~~~~~~~~~
> ./include/linux/sockptr.h:126:52: note: in expansion of macro ‘GFP_USER’
>   126 |         void *p = kmalloc_track_caller_noprof(len, GFP_USER | __GFP_NOWARN);
>       |                                                    ^~~~~~~~
>
> Perhaps it is time for a refresh and a new submission huh?

 Yeah, that time has long since passed, I'm sorry about the delay!
 
 I'm working on it as we speak. The submission I've been trying to
 post for the last few week is to add a __GFP_UNMAPPED flag. That will
 unblock the guest_memfd unmapped usecase.
 
 I got some design elements wrong and had to reimplement some stuff
 during January (I had an AI review my code and it pointed out that
 part of my pagetable management code was garbage. Spooky). Now I'm
 working on integrating the new version with the guest_memfd features to
 make sure it's actually fast (it's quite complicated so it had better
 be useful). Once that's done I'll hopefully be ready to post....

 _THEN_ I can update the __GFP_SENSITIVE functionality on top of the
 __GFP_UNMAPPED functionality. The former means "don't map into ASI"
 and the latter means "don't map at all" so they overlap in terms of
 allocator stuff.l