linux-stable.git/include/linux/gfp_types.h, branch v7.0.11

mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free

2026-06-01T15:54:21+00:00

commit 6a288a4ddb4a994490505ab5f41c445f8e6b6467 upstream.

__GFP_ZEROTAGS semantics are currently a bit weird, but effectively this
flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN.

If we run with init_on_free, we will zero out pages during
__free_pages_prepare(), to skip zeroing on the allocation path.

However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will
consequently not only skip clearing page content, but also skip clearing
tag memory.

Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that
will get mapped to user space through set_pte_at() later: set_pte_at() and
friends will detect that the tags have not been initialized yet
(PG_mte_tagged not set), and initialize them.

However, for the huge zero folio, which will be mapped through a PMD
marked as special, this initialization will not be performed, ending up
exposing whatever tags were still set for the pages.

The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state
that allocation tags are set to 0 when a page is first mapped to user
space.  That no longer holds with the huge zero folio when init_on_free is
enabled.

Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to
tag_clear_highpages() whether we want to also clear page content.

Invert the meaning of the tag_clear_highpages() return value to have
clearer semantics.

Reproduced with the huge zero folio by modifying the check_buffer_fill
arm64/mte selftest to use a 2 MiB area, after making sure that pages have
a non-0 tag set when freeing (note that, during boot, we will not actually
initialize tags, but only set KASAN_TAG_KERNEL in the page flags).

	$ ./check_buffer_fill
	1..20
	...
	not ok 17 Check initial tags with private mapping, sync error mode and mmap memory
	not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory
	...

This code needs more cleanups; we'll tackle that next, like
decoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN.

[akpm@linux-foundation.org: s/__GPF_ZERO/__GFP_ZERO/, per David]
Link: https://lore.kernel.org/20260421-zerotags-v2-1-05cb1035482e@kernel.org
Fixes: adfb6609c680 ("mm/huge_memory: initialise the tags of the huge zero folio")
Signed-off-by: David Hildenbrand (Arm) 
Reviewed-by: Catalin Marinas 
Tested-by: Lance Yang 
Cc: Brendan Jackman 
Cc: Dev Jain 
Cc: Johannes Weiner 
Cc: Liam Howlett 
Cc: Lorenzo Stoakes (Oracle) 
Cc: Mark Brown 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Ryan Roberts 
Cc: Suren Baghdasaryan 
Cc: Will Deacon 
Cc: Zi Yan 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

mm/slab: mark alloc tags empty for sheaves allocated with __GFP_NO_OBJ_EXT

2026-02-26T16:30:32+00:00

alloc_empty_sheaf() allocates sheaves from SLAB_KMALLOC caches using
__GFP_NO_OBJ_EXT to avoid recursion, however it does not mark their
allocation tags empty before freeing, which results in a warning when
CONFIG_MEM_ALLOC_PROFILING_DEBUG is set. Fix this by marking allocation
tags for such sheaves as empty.

The problem was technically introduced in commit 4c0a17e28340 but only
becomes possible to hit with commit 913ffd3a1bf5.

Fixes: 4c0a17e28340 ("slab: prevent recursive kmalloc() in alloc_empty_sheaf()")
Fixes: 913ffd3a1bf5 ("slab: handle kmalloc sheaves bootstrap")
Reported-by: David Wang <00107082@163.com>
Closes: https://lore.kernel.org/all/20260223155128.3849-1-00107082@163.com/
Analyzed-by: Harry Yoo 
Signed-off-by: Suren Baghdasaryan 
Reviewed-by: Harry Yoo 
Tested-by: Harry Yoo 
Tested-by: David Wang <00107082@163.com>
Link: https://patch.msgid.link/20260225163407.2218712-1-surenb@google.com
Signed-off-by: Vlastimil Babka (SUSE)

mm: clarify GFP_ATOMIC/GFP_NOWAIT doc-comment

2026-01-21T03:24:49+00:00

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.

Link: https://lore.kernel.org/all/d912480a-5229-4efe-9336-b31acded30f5@suse.cz/
Link: https://lkml.kernel.org/r/20251219-b4-gfp_atomic-comment-v2-1-4c4ce274c2b6@google.com
Signed-off-by: Brendan Jackman 
Acked-by: Vlastimil Babka 
Acked-by: David Hildenbrand (Red Hat) 
Cc: Liam Howlett 
Cc: Lorenzo Stoakes 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Sebastian Andrzej Siewior 
Cc: Steven Rostedt 
Cc: Suren Baghdasaryan 
Signed-off-by: Andrew Morton

slab: prevent recursive kmalloc() in alloc_empty_sheaf()

2025-11-07T08:59:15+00:00

We want to expand usage of sheaves to all non-boot caches, including
kmalloc caches. Since sheaves themselves are also allocated by
kmalloc(), we need to prevent excessive or infinite recursion -
depending on sheaf size, the sheaf can be allocated from smaller, same
or larger kmalloc size bucket, there's no particular constraint.

This is similar to allocating the objext arrays so let's just reuse the
existing mechanisms for those. __GFP_NO_OBJ_EXT in alloc_empty_sheaf()
will prevent a nested kmalloc() from allocating a sheaf itself - it will
either have sheaves already, or fallback to a non-sheaf-cached
allocation (so bootstrap of sheaves in a kmalloc cache that allocates
sheaves from its own size bucket is possible). Additionally, reuse
OBJCGS_CLEAR_MASK to clear unwanted gfp flags from the nested
allocation.

Link: https://patch.msgid.link/20251105-sheaves-cleanups-v1-5-b8218e1ac7ef@suse.cz
Reviewed-by: Harry Yoo 
Signed-off-by: Vlastimil Babka

mm: warn about illegal __GFP_NOFAIL usage in a more appropriate location and manner

2024-09-09T23:39:03+00:00

Three points for this change:

1. We should consolidate all warnings in one place. Currently, the
   order > 1 warning is in the hotpath, while others are in less
   likely scenarios. Moving all warnings to the slowpath will reduce
   the overhead for order > 1 and increase the visibility of other
   warnings.

2. We currently have two warnings for order: one for order > 1 in
   the hotpath and another for order > costly_order in the laziest
   path. I suggest standardizing on order > 1 since it's been in
   use for a long time.

3. We don't need to check for __GFP_NOWARN in this case. __GFP_NOWARN
   is meant to suppress allocation failure reports, but here we're
   dealing with bug detection, not allocation failures. So replace
   WARN_ON_ONCE_GFP by WARN_ON_ONCE.

[v-songbaohua@oppo.com: also update the doc for __GFP_NOFAIL with order > 1]
  Link: https://lkml.kernel.org/r/20240903223935.1697-1-21cnbao@gmail.com
Link: https://lkml.kernel.org/r/20240830202823.21478-4-21cnbao@gmail.com
Signed-off-by: Barry Song 
Suggested-by: Vlastimil Babka 
Reviewed-by: Vlastimil Babka 
Acked-by: David Hildenbrand 
Acked-by: Michal Hocko 
Cc: Christoph Hellwig 
Cc: Christoph Lameter 
Cc: Davidlohr Bueso 
Cc: David Rientjes 
Cc: "Eugenio Pérez" 
Cc: Hailong.Liu 
Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: Jason Wang 
Cc: Joonsoo Kim 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Lorenzo Stoakes 
Cc: Maxime Coquelin 
Cc: "Michael S. Tsirkin" 
Cc: Pekka Enberg 
Cc: Roman Gushchin 
Cc: Uladzislau Rezki (Sony) 
Cc: Xie Yongji 
Cc: Xuan Zhuo 
Cc: Yafang Shao 
Signed-off-by: Andrew Morton

mm: document __GFP_NOFAIL must be blockable

2024-09-09T23:39:03+00:00

Non-blocking allocation with __GFP_NOFAIL is not supported and may still
result in NULL pointers (if we don't return NULL, we result in busy-loop
within non-sleepable contexts):

static inline struct page *
__alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
						struct alloc_context *ac)
{
	...
	/*
	 * Make sure that __GFP_NOFAIL request doesn't leak out and make sure
	 * we always retry
	 */
	if (gfp_mask & __GFP_NOFAIL) {
		/*
		 * All existing users of the __GFP_NOFAIL are blockable, so warn
		 * of any new users that actually require GFP_NOWAIT
		 */
		if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask))
			goto fail;
		...
	}
	...
fail:
	warn_alloc(gfp_mask, ac->nodemask,
			"page allocation failure: order:%u", order);
got_pg:
	return page;
}

Highlight this in the documentation of __GFP_NOFAIL so that non-mm
subsystems can reject any illegal usage of __GFP_NOFAIL with GFP_ATOMIC,
GFP_NOWAIT, etc.

Link: https://lkml.kernel.org/r/20240830202823.21478-3-21cnbao@gmail.com
Signed-off-by: Barry Song 
Acked-by: Michal Hocko 
Reviewed-by: Christoph Hellwig 
Acked-by: Vlastimil Babka 
Acked-by: Davidlohr Bueso 
Acked-by: David Hildenbrand 
Cc: Christoph Lameter 
Cc: David Rientjes 
Cc: "Eugenio Pérez" 
Cc: Hailong.Liu 
Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: Jason Wang 
Cc: Joonsoo Kim 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Lorenzo Stoakes 
Cc: Maxime Coquelin 
Cc: "Michael S. Tsirkin" 
Cc: Pekka Enberg 
Cc: Roman Gushchin 
Cc: Uladzislau Rezki (Sony) 
Cc: Xuan Zhuo 
Cc: Christoph Hellwig 
Cc: Xie Yongji 
Cc: Yafang Shao 
Signed-off-by: Andrew Morton

mm: introduce __GFP_NO_OBJ_EXT flag to selectively prevent slabobj_ext creation

2024-04-26T03:55:51+00:00

Introduce __GFP_NO_OBJ_EXT flag in order to prevent recursive allocations
when allocating slabobj_ext on a slab.

Link: https://lkml.kernel.org/r/20240321163705.3067592-8-surenb@google.com
Signed-off-by: Suren Baghdasaryan 
Reviewed-by: Kees Cook 
Reviewed-by: Pasha Tatashin 
Reviewed-by: Vlastimil Babka 
Tested-by: Kees Cook 
Cc: Alexander Viro 
Cc: Alex Gaynor 
Cc: Alice Ryhl 
Cc: Andreas Hindborg 
Cc: Benno Lossin 
Cc: "Björn Roy Baron" 
Cc: Boqun Feng 
Cc: Christoph Lameter 
Cc: Dennis Zhou 
Cc: Gary Guo 
Cc: Kent Overstreet 
Cc: Miguel Ojeda 
Cc: Peter Zijlstra 
Cc: Tejun Heo 
Cc: Wedson Almeida Filho 
Signed-off-by: Andrew Morton

memblock tests: fix undefined reference to `BIT'

2024-04-04T08:08:33+00:00

commit 772dd0342727 ("mm: enumerate all gfp flags") define gfp flags
with the help of BIT, while gfp_types.h doesn't include header file for
the definition. This through an error on building memblock tests.

Let's include linux/bits.h to fix it.

Signed-off-by: Wei Yang 
CC: Suren Baghdasaryan 
CC: Michal Hocko 
Link: https://lore.kernel.org/r/20240402132701.29744-4-richard.weiyang@gmail.com
Signed-off-by: Mike Rapoport (IBM)

mm: enumerate all gfp flags

2024-03-05T01:01:18+00:00

Introduce GFP bits enumeration to let compiler track the number of used
bits (which depends on the config options) instead of hardcoding them. 
That simplifies __GFP_BITS_SHIFT calculation.

Link: https://lkml.kernel.org/r/20240224015800.2569851-1-surenb@google.com
Suggested-by: Petr Tesařík 
Signed-off-by: Suren Baghdasaryan 
Reviewed-by: Kees Cook 
Reviewed-by: Pasha Tatashin 
Acked-by: Michal Hocko 
Cc: Kent Overstreet 
Cc: Petr Tesarik 
Signed-off-by: Andrew Morton

gfp: gfp_types.h: fix typos & punctuation

2023-12-20T22:48:14+00:00

Correct typos/spellos and punctutation.

Link: https://lkml.kernel.org/r/20231213043316.10128-1-rdunlap@infradead.org
Signed-off-by: Randy Dunlap 
Signed-off-by: Andrew Morton