linux-kernel - Re: [PATCH] slab: Fix using this_cpu

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: <be2a3a3d-395d-4a0a-9c32-488212710c92@suse.cz>
Date: Fri, 3 Oct 2025 08:52:29 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Harry Yoo <harry.yoo@...cle.com>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>, ranxiaokai627@....com,
 Andrew Morton <akpm@...ux-foundation.org>, cl@...two.org,
 David Rientjes <rientjes@...gle.com>,
 Roman Gushchin <roman.gushchin@...ux.dev>,
 Alexei Starovoitov <ast@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
 linux-mm <linux-mm@...ck.org>, ran.xiaokai@....com.cn
Subject: Re: [PATCH] slab: Fix using this_cpu_ptr() in preemptible context

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.