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 AE9F92E2852 for ; Thu, 25 Jun 2026 05:40:37 +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=1782366038; cv=none; b=hPly53xtIRg8dNaxfU28v+Y/fs4cji9Ptp5TXz+y2uDh36JeVNj4+8OquCBfiOUKKtgVrNH8qwd/TsOSA06QN5SUoAtWLE+Ar4meooMp2BMuP5ChmpWi0a5l73UqCzrYY5lo108KmROQ81ZAbExwmePPIie8jyXHDGjjBhX6dEo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782366038; c=relaxed/simple; bh=kSMDyj+/pXDSduohkCwsYJq4ZsPV+Oe7APgYWBxRgnI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=czfFvWkhTlVG2ajcttYbGl9wS7TbMeDI31sCXh5AB9tH4N8DJb4vJpdw7flpfZvfMkXpfJtE5rwY++dz6mFzuMPRNmZhWltD/vmxlNsDoMoytOz4k2BHAuxfNn4y1Aqqr6ZSyrnc06cCNL5KWN1DkdAH6fnuYVGHc/okub0ZJF8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=omGmfD9F; 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="omGmfD9F" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93CA21F000E9; Thu, 25 Jun 2026 05:40:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782366037; bh=1CYx3XQgylaUzO4k8wNoEpO9t2hZ1nDpctVE/l57eTI=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=omGmfD9FsHrFxIi+oV06COrE6S3wY1T01d/W8zp/TBk39MMccWf67jXEQdLtkvWX0 dRk2Sh1cNw+B7Nk8Sez3VNAvEBkc2xkDIjk5QD2JOoM4BS5ve4VyAEu7JSAko6PdR9 JMBJ72xNs7pUrAUVL8cnNsav5X4j/3712669Xc3n93JhfFxLDkNpkcASUfEF/MmBY3 KGEfDUK41cOCyNszS84CbCpH4dOwAh9jyEUVCEOfSKsy+icZYVuHp0yYEMaJonEWYr exg/2JAoccuh+wtXORibtTbugnu6NnPL1KB/6q5VzyrTS4MUSsFT1C2seykSVXP/7i eBLYlbNBVJ1Tg== Message-ID: Date: Thu, 25 Jun 2026 14:40:31 +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 for-next v3 7/9] mm/slab: introduce kfree_rcu_nolock() To: hu.shengming@zte.com.cn Cc: vbabka@kernel.org, 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: <20260624172234202jw3y4yP1YfgOYbPCQdVIw@zte.com.cn> Content-Language: en-US From: Harry Yoo In-Reply-To: <20260624172234202jw3y4yP1YfgOYbPCQdVIw@zte.com.cn> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Gtjp5Uv2d3HsvH5Wirwk76EU" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Gtjp5Uv2d3HsvH5Wirwk76EU Content-Type: multipart/mixed; boundary="------------ton6HL0VdAY6bEx1XiSPETpG"; protected-headers="v1" From: Harry Yoo To: hu.shengming@zte.com.cn Cc: vbabka@kernel.org, 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 Message-ID: Subject: Re: [PATCH for-next v3 7/9] mm/slab: introduce kfree_rcu_nolock() References: <20260624172234202jw3y4yP1YfgOYbPCQdVIw@zte.com.cn> In-Reply-To: <20260624172234202jw3y4yP1YfgOYbPCQdVIw@zte.com.cn> --------------ton6HL0VdAY6bEx1XiSPETpG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/24/26 6:22 PM, hu.shengming@zte.com.cn wrote: > Harry wrote: >> Currently, k[v]free_rcu() cannot be called in unknown context since >> it could lead to a deadlock when called in the middle of k[v]free_rcu(= ). >> >> Make users' lives easier by introducing kfree_rcu_nolock() variant, >> now that kfree_rcu_sheaf() is available on PREEMPT_RT and >> __kfree_rcu_sheaf() handles unknown context. >> >> Unlike k[v]free_rcu(), kfree_rcu_nolock() does not fall back to >> the kvfree_rcu batching when the sheaves path fails, and falls back to= >> defer_kfree_rcu() instead. In most cases, the sheaves path is expected= >> to succeed and it's unnecessary to add complexity to the existing >> kvfree_rcu batching. >> >> Since defer_kfree_rcu() can be called on caches without sheaves, move >> deferred_work_barrier() and rcu_barrier() outside the branch in >> kvfree_rcu_barrier_on_cache(). >> >> Signed-off-by: Harry Yoo (Oracle) >=20 > Hi Harry, >=20 > Thanks for the series. These patches fill a clear functional gap in the= > existing free APIs by adding an RCU-deferred free interface for context= s > where kfree_rcu() cannot safely be used. Thanks for looking into this, Shengming. >> --- >> include/linux/rcupdate.h | 12 ++++++++++++ >> mm/slab.h | 1 + >> mm/slab_common.c | 22 ++++++++++++++++++++-- >> mm/slub.c | 23 ++++++++++++++++++++++- >> 4 files changed, 55 insertions(+), 3 deletions(-) >> >> diff --git a/mm/slab_common.c b/mm/slab_common.c >> index 807924a94fb0..5a39e6225160 100644 >> --- a/mm/slab_common.c >> +++ b/mm/slab_common.c >> @@ -1263,6 +1263,23 @@ EXPORT_TRACEPOINT_SYMBOL(kmem_cache_alloc); >> EXPORT_TRACEPOINT_SYMBOL(kfree); >> EXPORT_TRACEPOINT_SYMBOL(kmem_cache_free); >> =20 >> +void kfree_call_rcu_nolock(struct rcu_head *head, void *ptr) >> +{ >> + struct slab *slab; >> + struct kmem_cache *s; >> + >> + VM_WARN_ON_ONCE(is_vmalloc_addr(ptr) || !virt_to_slab(ptr)); >> + >> + slab =3D virt_to_slab(ptr); >> + s =3D slab->slab_cache; >> + >> + if (__kfree_rcu_sheaf(s, ptr, /* allow_spin =3D */ false)) >> + return; >> + >=20 > One consistency issue to address here: kfree_rcu_sheaf() only calls > __kfree_rcu_sheaf() for objects belonging to the local NUMA node. This > avoids filling a CPU's per-CPU sheaves with objects from remote slabs. >=20 > kfree_call_rcu_nolock() currently skips that check and may therefore > place remote-node objects into the local CPU's RCU sheaf. That was intentional, but actually, this is a good point. Thanks. > Could you add the same local-node check used by kfree_rcu_sheaf() > before calling __kfree_rcu_sheaf(), and route remote-node objects > directly to the defer_kfree_rcu() fallback path instead? Falling back to defer_kfree_rcu() in v3 didn't make much sense as the object is inserted to a global list which would cause more troubles than NUMA miss. But once we make the fallback path percpu, your suggestion would make more sense. --=20 Cheers, Harry / Hyeonggon --------------ton6HL0VdAY6bEx1XiSPETpG-- --------------Gtjp5Uv2d3HsvH5Wirwk76EU Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQQ1ub6gR5ogjaKRmOGXBN6rc5S1gUCajy/TwAKCRCGXBN6rc5S 1reCAQDbId1rvGbMDk6S+2sXzRMP61XyXQQ9nNAf7KHYJwdk8wD+OSS2WZN+8LCA npzV0tX4akpRMlyzoaZnWg0TSBQz3g0= =bUWa -----END PGP SIGNATURE----- --------------Gtjp5Uv2d3HsvH5Wirwk76EU--