From: Harry Yoo <harry.yoo@oracle.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: ranxiaokai627@163.com, akpm@linux-foundation.org, cl@gentwo.org,
rientjes@google.com, roman.gushchin@linux.dev, ast@kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
ran.xiaokai@zte.com.cn
Subject: Re: [PATCH] slab: Fix using this_cpu_ptr() in preemptible context
Date: Mon, 13 Oct 2025 16:00:15 +0900 [thread overview]
Message-ID: <aOyjfyCSgoIj_c_H@hyeyoo> (raw)
In-Reply-To: <f72deca7-4344-4adc-88e3-35a4a1d9a30b@suse.cz>
On Fri, Oct 03, 2025 at 09:49:57AM +0200, Vlastimil Babka wrote:
> On 9/30/25 10:34, ranxiaokai627@163.com wrote:
> > From: Ran Xiaokai <ran.xiaokai@zte.com.cn>
> >
> > defer_free() maybe called in preemptible context, this will
> > trigger the below warning message:
> >
> > BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
> > caller is defer_free+0x1b/0x60
> > Call Trace:
> > <TASK>
> > dump_stack_lvl+0xac/0xc0
> > check_preemption_disabled+0xbe/0xe0
> > defer_free+0x1b/0x60
> > kfree_nolock+0x1eb/0x2b0
> > alloc_slab_obj_exts+0x356/0x390
> > __alloc_tagging_slab_alloc_hook+0xa0/0x300
> > __kmalloc_cache_noprof+0x1c4/0x5c0
> > __set_page_owner+0x10d/0x1c0
> > post_alloc_hook+0x84/0xf0
> > get_page_from_freelist+0x73b/0x1380
> > __alloc_frozen_pages_noprof+0x110/0x2c0
> > alloc_pages_mpol+0x44/0x140
> > alloc_slab_page+0xac/0x150
> > allocate_slab+0x78/0x3a0
> > ___slab_alloc+0x76b/0xed0
> > __slab_alloc.constprop.0+0x5a/0xb0
> > __kmalloc_noprof+0x3dc/0x6d0
> > __list_lru_init+0x6c/0x210
> > alloc_super+0x3b6/0x470
> > sget_fc+0x5f/0x3a0
> > get_tree_nodev+0x27/0x90
> > vfs_get_tree+0x26/0xc0
> > vfs_kern_mount.part.0+0xb6/0x140
> > kern_mount+0x24/0x40
> > init_pipe_fs+0x4f/0x70
> > do_one_initcall+0x62/0x2e0
> > kernel_init_freeable+0x25b/0x4b0
> > kernel_init+0x1a/0x1c0
> > ret_from_fork+0x290/0x2e0
> > ret_from_fork_asm+0x11/0x20
> > </TASK>
> >
> > Replace this_cpu_ptr with raw_cpu_ptr to eliminate
> > the above warning message.
> >
> > Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().")
> > Signed-off-by: Ran Xiaokai <ran.xiaokai@zte.com.cn>
>
> Since the slab PR was merged, we should fix this ideally before rc1 so I
> updated the code myself per the discussion and added to slab/for-next
>
> Thanks!
>
> ----8<----
> From d6306a3d5577769b179ae4e448fd144e2b0f7717 Mon Sep 17 00:00:00 2001
> From: Ran Xiaokai <ran.xiaokai@zte.com.cn>
> Date: Tue, 30 Sep 2025 08:34:02 +0000
> Subject: [PATCH] slab: Fix using this_cpu_ptr() in preemptible context
>
> defer_free() maybe called in preemptible context, this will trigger the
> below warning message:
>
> BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
> caller is defer_free+0x1b/0x60
> Call Trace:
> <TASK>
> dump_stack_lvl+0xac/0xc0
> check_preemption_disabled+0xbe/0xe0
> defer_free+0x1b/0x60
> kfree_nolock+0x1eb/0x2b0
> alloc_slab_obj_exts+0x356/0x390
> __alloc_tagging_slab_alloc_hook+0xa0/0x300
> __kmalloc_cache_noprof+0x1c4/0x5c0
> __set_page_owner+0x10d/0x1c0
> post_alloc_hook+0x84/0xf0
> get_page_from_freelist+0x73b/0x1380
> __alloc_frozen_pages_noprof+0x110/0x2c0
> alloc_pages_mpol+0x44/0x140
> alloc_slab_page+0xac/0x150
> allocate_slab+0x78/0x3a0
> ___slab_alloc+0x76b/0xed0
> __slab_alloc.constprop.0+0x5a/0xb0
> __kmalloc_noprof+0x3dc/0x6d0
> __list_lru_init+0x6c/0x210
> alloc_super+0x3b6/0x470
> sget_fc+0x5f/0x3a0
> get_tree_nodev+0x27/0x90
> vfs_get_tree+0x26/0xc0
> vfs_kern_mount.part.0+0xb6/0x140
> kern_mount+0x24/0x40
> init_pipe_fs+0x4f/0x70
> do_one_initcall+0x62/0x2e0
> kernel_init_freeable+0x25b/0x4b0
> kernel_init+0x1a/0x1c0
> ret_from_fork+0x290/0x2e0
> ret_from_fork_asm+0x11/0x20
> </TASK>
>
> Disable preemption in defer_free() and also defer_deactivate_slab() to
> make it safe.
>
> [vbabka@suse.cz: disable preemption instead of using raw_cpu_ptr() per
> the discussion ]
> Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().")
> Signed-off-by: Ran Xiaokai <ran.xiaokai@zte.com.cn>
> Link: https://lore.kernel.org/r/20250930083402.782927-1-ranxiaokai627@163.com
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---
Looks good to me,
Reviewed-by: Harry Yoo <harry.yoo@oracle.com>
--
Cheers,
Harry / Hyeonggon
prev parent reply other threads:[~2025-10-13 7:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-30 8:34 [PATCH] slab: Fix using this_cpu_ptr() in preemptible context ranxiaokai627
2025-09-30 10:53 ` Harry Yoo
2025-09-30 11:19 ` Alexei Starovoitov
2025-10-02 8:14 ` Vlastimil Babka
2025-10-02 9:00 ` Harry Yoo
2025-10-03 6:52 ` Vlastimil Babka
2025-10-03 7:49 ` Vlastimil Babka
2025-10-03 15:01 ` Alexei Starovoitov
2025-10-13 7:00 ` Harry Yoo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aOyjfyCSgoIj_c_H@hyeyoo \
--to=harry.yoo@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--cc=cl@gentwo.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ran.xiaokai@zte.com.cn \
--cc=ranxiaokai627@163.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.