From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0D283215075 for ; Fri, 22 May 2026 01:22:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779412924; cv=none; b=Uh3F7/K93ehO9d4SNfBvDeiAYA6HVzFvVooH9GICPHfW2l/tK1jWptN1tTw2EExK1SEOzt4d91hreuzkksAGtZX8GaKu94PpVMPtqwy3oTDGCededd94fqdcGNant1gEdjlzzHlridwqhyKcTP8NTc66F+HwC2sfjC2T4jdYXdQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779412924; c=relaxed/simple; bh=IXRMk2GuaLbK2oXj5ai9pvAy7SlXRnBEKJYaadZWD/Q=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=BECFtv9wpZuIrUAGeKq9LknhwNCZl1E7Pg6+FOioNbaPPVB01I6FcC7GgqWB8GPTzJIHk59MAsR31+G70OolRVP+8Sj/O/Fa90qk/C0UDKdKAJXjraQG7rjFQn7t/iRUJFVFyfiX+UvdxWQHAJzcpSbiLI8tc7CRd3vGnvNtddg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VVeGbjFN; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VVeGbjFN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A60611F000E9; Fri, 22 May 2026 01:22:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779412922; bh=HxMygZ9hcsa3Mh208HkljC86oSSIEIIHQro19e3RuAk=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=VVeGbjFNPUPkrJABT5J1Fj9u/TOEEbIbtzWok+zXc8j1EcT4OY2LS30abX2IF1EYQ VbIPg0Bxnd3l2HlpwvjLMvFtua46E/dX/hqjUrfDwvJ0LQCLWpOIn0PrC6CLE6pZ2b sm1Aoqny6pCkP2i34Z+6qOiE1sxtpvpVEBjacr7i+GLI1gl7Cjylo9spe/o9SHRCfS v43sv/qcTYodJoIXELyW7j/5pwN4IfU1rYjzorR67F6koNCjuww29MF9+Se9dUPBbW Ybld5vypp66mo0HAdeb0I+GcUf/He4hXyschxSfpM6mQ41lm/ka1SQUpH59Y00fc4a 2qaVCaKlFEGZw== Message-ID: <13fd910b-e897-4a9d-847a-545267209bf8@kernel.org> Date: Fri, 22 May 2026 10:21:58 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/slub: free returned pfmemalloc sheaves via free_empty_sheaf() To: hu.shengming@zte.com.cn, vbabka@kernel.org, akpm@linux-foundation.org Cc: hao.li@linux.dev, cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, zhang.run@zte.com.cn, cai.qu@zte.com.cn References: <20260521195015105Y4zvKHj0TfPZEujixy9Vo@zte.com.cn> Content-Language: en-US From: Harry Yoo In-Reply-To: <20260521195015105Y4zvKHj0TfPZEujixy9Vo@zte.com.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Shengming, On 5/21/26 8:50 PM, hu.shengming@zte.com.cn wrote: > From: Shengming Hu > > Regular sized sheaves are allocated through alloc_empty_sheaf(), which > sets __GFP_NO_OBJ_EXT. free_empty_sheaf() is the matching free helper > for such sheaves. It marks kmalloc sheaves with an empty codetag before > kfree(), avoiding the alloc_tag_sub() warning for intentionally missing > object extensions. > > kmem_cache_return_sheaf() currently handles returned pfmemalloc sheaves > in the same branch as oversize sheaves and uses kfree(). That is right > for oversize sheaves, which are allocated directly with kzalloc_flex(), > but it misses the matching free path for regular sized pfmemalloc sheaves > that came from alloc_empty_sheaf(). I think it'd be better (in terms of readability) to teach alloc_empty_sheaf() how to allocate and initialize an oversized empty sheaf, and always free empty sheaves with free_empty_sheaf(). > Split the two cases. Keep plain kfree() for capacity-mismatched oversize > sheaves, and use free_empty_sheaf() after flushing returned pfmemalloc > regular sheaves. > > Fixes: <1ce20c2> ("slab: handle pfmemalloc slabs properly with sheaves") When referring to a commit, the commit id should contain at least 12 characters to avoid collisions (per the process document). ...but probably Fixes: is not needed at all, because currently no user uses kmalloc caches to allocate prefilled sheaves. > Signed-off-by: Shengming Hu > --- > mm/slub.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/mm/slub.c b/mm/slub.c > index 04692a6f9128..a6b720fa79ad 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -5094,13 +5094,18 @@ void kmem_cache_return_sheaf(struct kmem_cache *s, gfp_t gfp, > struct slub_percpu_sheaves *pcs; > struct node_barn *barn; > > - if (unlikely((sheaf->capacity != s->sheaf_capacity) > - || sheaf->pfmemalloc)) { > + if (unlikely(sheaf->capacity != s->sheaf_capacity)) { > sheaf_flush_unused(s, sheaf); > kfree(sheaf); > return; > } > > + if (unlikely(sheaf->pfmemalloc)) { > + sheaf_flush_unused(s, sheaf); > + free_empty_sheaf(s, sheaf); > + return; > + } > + > local_lock(&s->cpu_sheaves->lock); > pcs = this_cpu_ptr(s->cpu_sheaves); > barn = get_barn(s); -- Cheers, Harry / Hyeonggon