From: Vlastimil Babka <vbabka@suse.cz>
To: Harry Yoo <harry.yoo@oracle.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
ranxiaokai627@163.com, Andrew Morton <akpm@linux-foundation.org>,
cl@gentwo.org, David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Alexei Starovoitov <ast@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
ran.xiaokai@zte.com.cn
Subject: Re: [PATCH] slab: Fix using this_cpu_ptr() in preemptible context
Date: Fri, 3 Oct 2025 08:52:29 +0200 [thread overview]
Message-ID: <be2a3a3d-395d-4a0a-9c32-488212710c92@suse.cz> (raw)
In-Reply-To: <aN4_PeDcDQUhv6N-@hyeyoo>
On 10/2/25 11:00, Harry Yoo wrote:
> On Thu, Oct 02, 2025 at 10:14:55AM +0200, Vlastimil Babka wrote:
>> However...
>> > Is this PREEMPT_RT ?
>> >
>> >> > __alloc_tagging_slab_alloc_hook+0xa0/0x300
>> >> > __kmalloc_cache_noprof+0x1c4/0x5c0
>> >> > __set_page_owner+0x10d/0x1c0
>>
>> This is the part that puzzles me, where do we call kmalloc from
>> __set_page_owner()?
>
> It's
>
> __set_page_owner()
> -> inc_stack_record_count()
> -> add_stack_record_to_list()
> -> kmalloc().
Thanks, missed that.
>> And in a way that it loses the GFP_KERNEL passed all the
>> way? I don't even see a lib/stackdepot function here.
>
> Oh wait, we clear __GFP_RECLAIM on the first attempt to allocate
> high-order slabs. so gfpflags_allow_spinning() returns false.
Ah right! Dang, that's suboptimal that we intend to do an opportunistic
attempt, but limit the allocations of supplementary objects this way. But I
don't see how to avoid this without inventing new gfp flags.
next prev parent reply other threads:[~2025-10-03 6:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-30 8:34 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 [this message]
2025-10-03 7:49 ` Vlastimil Babka
2025-10-03 15:01 ` Alexei Starovoitov
2025-10-13 7:00 ` Harry Yoo
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=be2a3a3d-395d-4a0a-9c32-488212710c92@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=cl@gentwo.org \
--cc=harry.yoo@oracle.com \
--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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox