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 22F5A3E3144; Wed, 27 May 2026 08:51:48 +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=1779871910; cv=none; b=OPOx11vl4n20Nqukz0DdLWJEHJaWDde8E9y4Q4KnobfxT/RKt8DnenwkkniH9rtjsz+2JMpVWTwaFKkpv7Nt8YC7ci+ixTf2i8jclDsluSP7UN5rDEY6ms2Sih00QlhJrbGBgU54SM35kltNA8CTvZ0zOzjl9WSCjKj80rEktQ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779871910; c=relaxed/simple; bh=+hPcOcfHsa8a3ANFA1UCHnJst8TfVpFirCBR15QJVio=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=snCrvFk/6PNMXyqtjawrfSAn2lQ8EUGRHJiehzK6zgvyHGr1QfxOxttUFjhhmf4wr9VHxRZCgYivo7mePBaDrddxR+dhnOnMO2FcuX2izlJoUjHwocdctYssCIIv6zgAnCcYCKAuJicKpE97jE0xkGlV5TVbu9kHRP7CVsAjmEw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=A4bj/hmQ; 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="A4bj/hmQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6AD71F00A3D; Wed, 27 May 2026 08:51:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779871908; bh=cw6Hq3fwY9dORsY8hW5a014rXACoZ3Q9ELeTsBjnSJM=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=A4bj/hmQa3H0KsSybQA679jZY8C2M2EBxCmGFd4kLjKqsNk3QWKHZjyPK5mXRkcfX VpWCAte43G/7b72JGRYwED2VJuyypr5CTDlz+B/TBjr+N205H33pNj87fbEH7GjTMD f4IzoJPCYeB66bnO4D2+DjO3keQikG9pILexzAijVpqCIMzJOir5m7RmSLWK4oBGUx HpxXjQHd9D1kqOUe/dWA+5FlGHtZur/fBmi1sPvyfdRgQVFYYfU4QdQGQhpaG5w5EU Y1D1Hds9rZPfYSD7ptH/l2KRCdPsgF384y4fFB2IicC6PJSaekfzn3Pg06DbJM/mVv ywTh7ch9dWuXw== Message-ID: Date: Wed, 27 May 2026 10:51:42 +0200 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/slab: improve kmem_cache_alloc_bulk To: Christoph Hellwig , Vlastimil Babka , Harry Yoo , Andrew Morton Cc: Hao Li , Christoph Lameter , David Rientjes , Roman Gushchin , linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, io-uring@vger.kernel.org, kasan-dev@googlegroups.com, bpf@vger.kernel.org, netdev@vger.kernel.org, Alexander Lobakin , Matt Fleming , kernel-team References: <20260527070239.2252948-1-hch@lst.de> <20260527070239.2252948-2-hch@lst.de> Content-Language: en-US From: Jesper Dangaard Brouer In-Reply-To: <20260527070239.2252948-2-hch@lst.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 27/05/2026 09.02, Christoph Hellwig wrote: > The kmem_cache_alloc_bulk return value is weird. It returns the number > of allocated objects, but that must always be 0 or the requested number > based on the implementations and the handling in the callers, but that > assumption is not actually documented anywhere, which confuses automated > review tools. > I remember, this API behavior was requested by AKPM when I developed kmem_cache_alloc_bulk. I trusted AKPM's decision, but I cannot explain why this choice was made. I kept the netdev code usage below. The current napi_skb_cache_get_bulk have a retry logic that assumes that a partial bulk number can be returned (which it cannot as Hellwig explains). Cc Alex/Olek please review the changes below as you added this retry logic. > Fix this by returning a bool if the allocation succeeded and adding a > kerneldoc comment explaining the API. > > Signed-off-by: Christoph Hellwig > --- > drivers/gpu/drm/msm/msm_iommu.c | 6 +-- > drivers/gpu/drm/panthor/panthor_mmu.c | 12 +++--- > include/linux/slab.h | 6 ++- > io_uring/io_uring.c | 23 +++++------ > lib/test_meminit.c | 19 +++++---- > mm/kasan/kasan_test_c.c | 5 +-- > mm/kfence/kfence_test.c | 9 +++-- > mm/slub.c | 58 +++++++++++++++------------ > net/bpf/test_run.c | 7 ++-- > net/core/skbuff.c | 24 ++++++----- > tools/include/linux/slab.h | 2 +- > tools/testing/shared/linux.c | 19 ++++----- > 12 files changed, 93 insertions(+), 97 deletions(-) > [...] > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 44ac121cfccb..73045b688385 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -288,11 +288,11 @@ static inline struct sk_buff *napi_skb_cache_get(bool alloc) > > local_lock_nested_bh(&napi_alloc_cache.bh_lock); > if (unlikely(!nc->skb_count)) { > - if (alloc) > - nc->skb_count = kmem_cache_alloc_bulk(net_hotdata.skbuff_cache, > - GFP_ATOMIC | __GFP_NOWARN, > - NAPI_SKB_CACHE_BULK, > - nc->skb_cache); > + if (alloc && kmem_cache_alloc_bulk(net_hotdata.skbuff_cache, > + GFP_ATOMIC | __GFP_NOWARN, > + NAPI_SKB_CACHE_BULK, > + nc->skb_cache)) > + nc->skb_count = NAPI_SKB_CACHE_BULK; > if (unlikely(!nc->skb_count)) { > local_unlock_nested_bh(&napi_alloc_cache.bh_lock); > return NULL; > @@ -353,16 +353,18 @@ u32 napi_skb_cache_get_bulk(void **skbs, u32 n) > > /* No enough cached skbs. Try refilling the cache first */ > bulk = min(NAPI_SKB_CACHE_SIZE - nc->skb_count, NAPI_SKB_CACHE_BULK); > - nc->skb_count += kmem_cache_alloc_bulk(net_hotdata.skbuff_cache, > - GFP_ATOMIC | __GFP_NOWARN, bulk, > - &nc->skb_cache[nc->skb_count]); > + if (kmem_cache_alloc_bulk(net_hotdata.skbuff_cache, > + GFP_ATOMIC | __GFP_NOWARN, bulk, > + &nc->skb_cache[nc->skb_count])) > + nc->skb_count += bulk; > if (likely(nc->skb_count >= n)) > goto get; > > /* Still not enough. Bulk-allocate the missing part directly, zeroed */ > - n -= kmem_cache_alloc_bulk(net_hotdata.skbuff_cache, > - GFP_ATOMIC | __GFP_ZERO | __GFP_NOWARN, > - n - nc->skb_count, &skbs[nc->skb_count]); > + if (kmem_cache_alloc_bulk(net_hotdata.skbuff_cache, > + GFP_ATOMIC | __GFP_ZERO | __GFP_NOWARN, > + n - nc->skb_count, &skbs[nc->skb_count])) > + n = nc->skb_count; > if (likely(nc->skb_count >= n)) > goto get; >