Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v2 13/16] mm/slab: allow __GFP_NOMEMALLOC and __GFP_NOWARN for kmalloc_nolock()
@ 2026-06-12 12:52 hu.shengming
  2026-06-12 13:00 ` Vlastimil Babka (SUSE)
  0 siblings, 1 reply; 6+ messages in thread
From: hu.shengming @ 2026-06-12 12:52 UTC (permalink / raw)
  To: vbabka
  Cc: harry, akpm, hao.li, cl, rientjes, roman.gushchin, linux-mm,
	linux-kernel, zhang.run, cai.qu

Vlastimil Babka (SUSE) wrote:
> The two flags are added internally so there's no point for warning if
> they are passed by the caller as well, so allow them. This will allow
> simplifying obj_ext allocation under kmalloc_nolock().
> 
> Also it's not necessary to have the extra alloc_gfp variable for adding
> the two flags. The original gfp_flags parameter is not used anywhere
> except for the warning. So remove alloc_gfp and directly modify and use
> gfp_flags everywhere.
> 
> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
>  include/linux/slab.h |  3 ++-
>  mm/slub.c            | 19 ++++++++++---------
>  2 files changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index ce1c867dc0ba..b955f3cbb732 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -1040,7 +1040,8 @@ void *_kmalloc_nolock_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t gfp_flags, in
>   * kmalloc_nolock - Allocate an object of given size from any context.
>   * @size: size to allocate
>   * @gfp_flags: GFP flags. Only __GFP_ACCOUNT, __GFP_ZERO, __GFP_NO_OBJ_EXT
> - * allowed.
> + * allowed. Also __GFP_NOWARN and __GFP_NOMEMALLOC are allowed but added
> + * internally thus not necessary.
>   * @node: node number of the target node.
>   *
>   * Return: pointer to the new object or NULL in case of error.
> diff --git a/mm/slub.c b/mm/slub.c
> index 6845e15c148a..847cad5203b2 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -5388,7 +5388,6 @@ EXPORT_SYMBOL(__kmalloc_noprof);
>  
>  void *_kmalloc_nolock_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t gfp_flags, int node)
>  {
> -	gfp_t alloc_gfp = __GFP_NOWARN | __GFP_NOMEMALLOC | gfp_flags;
>  	size_t orig_size = size;
>  	unsigned int alloc_flags = SLAB_ALLOC_TRYLOCK;
>  	struct kmem_cache *s;
> @@ -5396,7 +5395,9 @@ void *_kmalloc_nolock_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t gfp_flags, in
>  	void *ret;
>  
>  	VM_WARN_ON_ONCE(gfp_flags & ~(__GFP_ACCOUNT | __GFP_ZERO |
> -				      __GFP_NO_OBJ_EXT));
> +			__GFP_NO_OBJ_EXT | __GFP_NOWARN | __GFP_NOMEMALLOC));
> +
> +	gfp_flags |= __GFP_NOWARN | __GFP_NOMEMALLOC;
>  

Hi Vlastimil,

While reviewing your patch, I spotted a potential GFP flag mismatch along the kmalloc_flags()
-> __kmalloc_nolock_noprof() call path. I cloned the slab/for-next branch to verify this and
successfully triggered a VM_WARN_ON_ONCE() in the __kmalloc_nolock_noprof() path.

Here is the observed trace:

[   57.283791] ------------[ cut here ]------------
[   57.284226] WARNING: mm/slub.c:5407 at __kmalloc_nolock_noprof+0x3ec/0x450, CPU#6: insmod/379
[   57.285060] Modules linked in: slub_nolock(O+)
[   57.285494] CPU: 6 UID: 0 PID: 379 Comm: insmod Tainted: G           O        7.1.0-rc3-00036-g5ade53586fae-dirty #5 PREEMPT(lazy) 
[   57.286608] Tainted: [O]=OOT_MODULE
[   57.286941] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[   57.288018] RIP: 0010:__kmalloc_nolock_noprof+0x3ec/0x450
[   57.288543] Code: 01 00 8b 4c 24 04 41 89 c2 e9 dd fc ff ff b8 10 00 00 00 e9 f9 fd ff ff 90 0f 0b 90 f7 04 24 ff de b7 ff 0f 84 54
[   57.290252] RSP: 0018:ffffa82840c73b68 EFLAGS: 00010206
[   57.290752] RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffa82840c73bc8
[   57.291428] RDX: 0000000000000000 RSI: 00000000002c2100 RDI: 0000000000000100
[   57.292124] RBP: 0000000000000000 R08: ffffffffb853c968 R09: 0000000000009ffb
[   57.292821] R10: 00000000000001d7 R11: ffffffffb850c980 R12: 00000000002c2100
[   57.293485] R13: 0000000000000000 R14: ffffa82840c73bc8 R15: 0000000000000003
[   57.294159] FS:  0000000006fa8880(0000) GS:ffff8f4ef9d5a000(0000) knlGS:0000000000000000
[   57.294914] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   57.295464] CR2: 0000000006fac528 CR3: 000000003f9b6003 CR4: 0000000000770ef0
[   57.296124] PKRU: 55555554
[   57.296443] Call Trace:
[   57.296702]  <TASK>
[   57.296914]  ? vprintk_emit+0x22e/0x280
[   57.297295]  __kmalloc_flags_noprof+0x216/0x530
[   57.297735]  ? _printk+0x56/0x70
[   57.298053]  ? alloc_slab_obj_exts+0x89/0x1e0
[   57.298474]  alloc_slab_obj_exts+0x89/0x1e0
[   57.298876]  new_slab+0x2bc/0x660
[   57.299200]  ___slab_alloc+0x2ae/0x660
[   57.299603]  __kmalloc_nolock_noprof+0x151/0x450
[   57.300050]  _kmalloc_nolock_noprof+0x47/0x70
[   57.300490]  ? slub_nolock_init+0x127/0xff0 [slub_nolock]
[   57.301013]  slub_nolock_init+0x127/0xff0 [slub_nolock]
[   57.301566]  ? __pfx_slub_nolock_init+0x10/0x10 [slub_nolock]
[   57.302197]  do_one_initcall+0x44/0x220
[   57.302598]  ? do_init_module+0x1e/0x240
[   57.302990]  do_init_module+0x5f/0x240
[   57.303357]  __do_sys_init_module+0x162/0x190
[   57.303783]  do_syscall_64+0xf7/0x550
[   57.304159]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[   57.304648] RIP: 0033:0x4b8839
[   57.304954] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 40
[   57.306676] RSP: 002b:00007ffea38fdce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
[   57.307376] RAX: ffffffffffffffda RBX: 00007ffea38fe080 RCX: 00000000004b8839
[   57.308044] RDX: 000000000062d4b5 RSI: 0000000000002790 RDI: 0000000006fa9d20
[   57.308710] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000002790
[   57.309366] R10: 0000000006fa9cc0 R11: 0000000000000246 R12: 00007ffea38fe088
[   57.310040] R13: 000000000062d4b5 R14: 0000000000000000 R15: 0000000000000000
[   57.310737]  </TASK>
[   57.310963] ---[ end trace 0000000000000000 ]---

With "# CONFIG_KMALLOC_PARTITION_CACHES is not set":
RSI: 00000000002c2100 -> gfp_flags

Decoding the GFP bits:

  0x00000100 = __GFP_ZERO
  0x00002000 = __GFP_NOWARN
  0x00080000 = __GFP_NOMEMALLOC
  0x00040000 = __GFP_COMP
  0x00200000 = __GFP_THISNODE

The root cause:

Previously, the obj_ext allocation path(alloc_slab_obj_exts()) called kmalloc_nolock() with a
fixed set of flags(__GFP_ZERO | __GFP_NO_OBJ_EXT). After switching to kmalloc_flags(), the
full GFP mask from the upper allocation path propagates through the call chain.

In detail, ___slab_alloc() may append __GFP_THISNODE, and allocate_slab() adds __GFP_COMP
via s->allocflags. Both flags flow down unchanged into __kmalloc_nolock_noprof().

This patch only permits four flags (__GFP_ACCOUNT, __GFP_ZERO, __GFP_NOWARN and __GFP_NOMEMALLOC).
Since neither __GFP_THISNODE nor __GFP_COMP is in the allowed set, the warning is triggered.

Would the following fix be acceptable?

    +#define KMALLOC_NOLOCK_ALLOWED_GFP \
    +       (__GFP_ACCOUNT | __GFP_ZERO | __GFP_NOWARN | __GFP_NOMEMALLOC)
    +
    /*
    * The only version of kmalloc_node() that takes alloc_flags and thus can
    * determine on its own whether to handle the allocation via kmalloc_nolock() or
    @@ -5548,6 +5564,7 @@ void *__kmalloc_flags_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t flags,
                    return __do_kmalloc_node(size, NULL, flags, node,
                                    PASS_TOKEN_PARAM(token), &ac);
            } else {
    +               flags &= KMALLOC_NOLOCK_ALLOWED_GFP;
                    return __kmalloc_nolock_noprof(PASS_TOKEN_PARAMS(size, token),
                                                flags, node, &ac);
            }

--
With Best Regards,
Shengming

>  	if (unlikely(!size))
>  		return ZERO_SIZE_PTR;
> @@ -5415,7 +5416,7 @@ void *_kmalloc_nolock_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t gfp_flags, in
>  retry:
>  	if (unlikely(size > KMALLOC_MAX_CACHE_SIZE))
>  		return NULL;
> -	s = kmalloc_slab(size, NULL, alloc_gfp, PASS_TOKEN_PARAM(token));
> +	s = kmalloc_slab(size, NULL, gfp_flags, PASS_TOKEN_PARAM(token));
>  
>  	if (!(s->flags & __CMPXCHG_DOUBLE) && !kmem_cache_debug(s))
>  		/*
> @@ -5429,7 +5430,7 @@ void *_kmalloc_nolock_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t gfp_flags, in
>  		 */
>  		return NULL;
>  
> -	ret = alloc_from_pcs(s, alloc_gfp, alloc_flags, node);
> +	ret = alloc_from_pcs(s, gfp_flags, alloc_flags, node);
>  	if (ret)
>  		goto success;
>  
> @@ -5445,7 +5446,7 @@ void *_kmalloc_nolock_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t gfp_flags, in
>  	 * kfence_alloc. Hence call __slab_alloc_node() (at most twice)
>  	 * and slab_post_alloc_hook() directly.
>  	 */
> -	ret = __slab_alloc_node(s, alloc_gfp, node, &ac);
> +	ret = __slab_alloc_node(s, gfp_flags, node, &ac);
>  
>  	/*
>  	 * It's possible we failed due to trylock as we preempted someone with
> @@ -5458,8 +5459,8 @@ void *_kmalloc_nolock_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t gfp_flags, in
>  		size = s->object_size + 1;
>  		/*
>  		 * Another alternative is to
> -		 * if (memcg) alloc_gfp &= ~__GFP_ACCOUNT;
> -		 * else if (!memcg) alloc_gfp |= __GFP_ACCOUNT;
> +		 * if (memcg) gfp_flags &= ~__GFP_ACCOUNT;
> +		 * else if (!memcg) gfp_flags |= __GFP_ACCOUNT;
>  		 * to retry from bucket of the same size.
>  		 */
>  		can_retry = false;
> @@ -5468,9 +5469,9 @@ void *_kmalloc_nolock_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t gfp_flags, in
>  
>  success:
>  	maybe_wipe_obj_freeptr(s, ret);
> -	slab_post_alloc_hook(s, alloc_gfp, 1, &ret, &ac);
> +	slab_post_alloc_hook(s, gfp_flags, 1, &ret, &ac);
>  
> -	ret = kasan_kmalloc(s, ret, orig_size, alloc_gfp);
> +	ret = kasan_kmalloc(s, ret, orig_size, gfp_flags);
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(_kmalloc_nolock_noprof);
> 
> -- 
> 2.54.0
>


^ permalink raw reply	[flat|nested] 6+ messages in thread
* [PATCH v2 00/16] mm/slab: introduce alloc_flags and slab_alloc_context
@ 2026-06-10 15:40 Vlastimil Babka (SUSE)
  2026-06-10 15:40 ` [PATCH v2 13/16] mm/slab: allow __GFP_NOMEMALLOC and __GFP_NOWARN for kmalloc_nolock() Vlastimil Babka (SUSE)
  0 siblings, 1 reply; 6+ messages in thread
From: Vlastimil Babka (SUSE) @ 2026-06-10 15:40 UTC (permalink / raw)
  To: Harry Yoo
  Cc: Hao Li, Christoph Lameter, David Rientjes, Roman Gushchin,
	Suren Baghdasaryan, Alexei Starovoitov, Andrew Morton,
	Johannes Weiner, Michal Hocko, Shakeel Butt, Alexander Potapenko,
	Marco Elver, Dmitry Vyukov, kasan-dev, linux-mm, linux-kernel,
	cgroups, Vlastimil Babka (SUSE), stable

This series is based on slab/for-next. As suggested by Alexei I will
try to put it there ASAP (hence the early respin) and see if it looks
stable enough to be send in the second 7.2 merge window week.

Git: https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=b4/slab_alloc_flags

The slab implementation currently relies on gfp flags to convey
some context information internally:

- The absence of both __GFP_RECLAIM flags is interpreted as "cannot spin
  on locks", and intended to be used by kmalloc_nolock(). But false
  positives are possible e.g. during early boot where gfp_allowed_mask
  clears __GFP_RECLAIM from all allocations. This leads to unnecessary
  allocation failures and workarounds such as fd3634312a04 ("debugobject:
  Make it work with deferred page initialization - again").

- __GFP_NO_OBJ_EXT exists and takes up valuable bit in the gfp flags
  space, only to prevent recursive kmalloc() allocations for obj_ext
  arrays and sheaves.

The page allocator uses its internal alloc_flags to convey various
context information, including ALLOC_TRYLOCK (meaning "cannot spin").
This series copies that concept for the slab allocator, with its own
slab-specific internal flags:

- SLAB_ALLOC_DEFAULT - no extra flags (the value is 0), but explicit
- SLAB_ALLOC_TRYLOCK - do not spin on locks (used by kmalloc_nolock())
- SLAB_ALLOC_NEW_SLAB - replacing existing 'bool new_slab' parameter
			for allocating obj_ext arrays
- SLAB_ALLOC_NO_RECURSE - replacing usage of __GFP_NO_OBJ_EXT

To reduce the amount of parameters in various internal functions, we
additionally introduce slab_alloc_context (also inspired by page
allocator's alloc_context) for passing a number of existing arguments
and the new alloc_flags:

/* Structure holding extra parameters for slab allocations */
struct slab_alloc_context {
	unsigned long caller_addr;
	unsigned long orig_size;
	unsigned int alloc_flags;
	struct list_lru *lru;
};

This also replaces the existing struct partial_context.

The last necessary piece is kmalloc_flags() which can take the
alloc_flags in addition to gfp flags and is intended for the recursive
allocations of sheaves and obj_ext arrays, so that both
SLAB_ALLOC_TRYLOCK and SLAB_ALLOC_NO_RECURSE can be communicated.
Internally it decides between kmalloc_nolock() and normal kmalloc()
depending SLAB_ALLOC_TRYLOCK.

The rest of the series is gradually expanding the usage of both
alloc_flags and slab_alloc_context as necessary, with bits of
refactoring. Then, __GFP_NO_OBJ_EXT is removed completely.

Note that some usage of gfpflags_allow_spinning() relying on absence of
__GFP_RECLAIM remains outside of slab (and page allocator) in memcg,
page_owner and stackdepot code. These can thus yield false-positive
decisions that spinning is not allowed, but should not result in
important allocations failing anymore.

Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
---
Changes in v2:
- Due to Sashiko review, drop the idea of zeroing orig_size
  unconditionally, as it can break krealloc(). Thanks to that found a
  pre-existing bug fixed by the new Patch 1. The kfence zeroing related
  cleanup is implemented differently in Patch 2.
- Prevent nested kmalloc_nolock warnings due to added gfp flags
  (Sashiko)
- Fix a pre-existing issue with opportunistic slab allocation from the
  target node only effectively dropping __GFP_NOMEMALLOC and __GFP_RECLAIM.
  (Sashiko)
- Move kmalloc_flags() definitions to mm/slab.h (per Harry).
- Link to v1: https://patch.msgid.link/20260609-slab_alloc_flags-v1-0-2bf4a4b9b526@kernel.org

---
Vlastimil Babka (SUSE) (16):
      mm/slab: do not limit zeroing to orig_size when only red zoning is enabled
      mm/slab: do not init any kfence objects on allocation
      mm/slab: stop inlining __slab_alloc_node()
      mm/slab: introduce slab_alloc_context
      mm/slab: introduce alloc_flags and SLAB_ALLOC_TRYLOCK
      mm/slab: add alloc_flags to slab_alloc_context
      mm/slab: replace struct partial_context with slab_alloc_context
      mm/slab: pass alloc_flags to new slab allocation
      mm/slab: pass alloc_flags through slab_post_alloc_hook() chain
      mm/slab: replace slab_alloc_node() parameters with slab_alloc_context
      mm/slab: allow kmem_cache_alloc_bulk() with any gfp flags
      mm/slab: pass slab_alloc_context to __do_kmalloc_node()
      mm/slab: allow __GFP_NOMEMALLOC and __GFP_NOWARN for kmalloc_nolock()
      mm/slab: introduce kmalloc_flags()
      mm/slab: remove __GFP_NO_OBJ_EXT usage from alloc_slab_obj_exts()
      mm/slab: replace __GFP_NO_OBJ_EXT with SLAB_ALLOC_NO_RECURSE for sheaves

 include/linux/slab.h |   5 +-
 mm/kfence/core.c     |   2 +-
 mm/memcontrol.c      |   5 +-
 mm/slab.h            |  29 +++-
 mm/slub.c            | 439 +++++++++++++++++++++++++++++++--------------------
 5 files changed, 304 insertions(+), 176 deletions(-)
---
base-commit: 500b2c9755301742bdbb61249511ac11a4665dae
change-id: 20260601-slab_alloc_flags-25c782b0c57c

Best regards,
--  
Vlastimil Babka (SUSE) <vbabka@kernel.org>



^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-06-15  5:06 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-12 12:52 [PATCH v2 13/16] mm/slab: allow __GFP_NOMEMALLOC and __GFP_NOWARN for kmalloc_nolock() hu.shengming
2026-06-12 13:00 ` Vlastimil Babka (SUSE)
2026-06-12 13:14   ` hu.shengming
  -- strict thread matches above, loose matches on Subject: below --
2026-06-10 15:40 [PATCH v2 00/16] mm/slab: introduce alloc_flags and slab_alloc_context Vlastimil Babka (SUSE)
2026-06-10 15:40 ` [PATCH v2 13/16] mm/slab: allow __GFP_NOMEMALLOC and __GFP_NOWARN for kmalloc_nolock() Vlastimil Babka (SUSE)
2026-06-12  6:57   ` Hao Li
2026-06-15  5:06     ` Suren Baghdasaryan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox