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: <20260128153834.GNaXotelMi3QMuvh9-@fat_crate.local>
Date: Wed, 28 Jan 2026 16:38:34 +0100
From: Borislav Petkov <bp@...en8.de>
To: 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 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?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette