From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CCC07CF8857 for ; Fri, 4 Oct 2024 21:25:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4BC6E6B03E2; Fri, 4 Oct 2024 17:25:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 444B56B03E4; Fri, 4 Oct 2024 17:25:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BF196B03E5; Fri, 4 Oct 2024 17:25:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 09B236B03E2 for ; Fri, 4 Oct 2024 17:25:46 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id AF96281B10 for ; Fri, 4 Oct 2024 21:25:45 +0000 (UTC) X-FDA: 82637201850.16.099C7D6 Received: from out-171.mta1.migadu.com (out-171.mta1.migadu.com [95.215.58.171]) by imf07.hostedemail.com (Postfix) with ESMTP id D0DFE40004 for ; Fri, 4 Oct 2024 21:25:43 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=FxvE+Uxp; spf=pass (imf07.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.171 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728077013; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cYKtCoATsBvcWFCPa9gSKY/ijfwd28CJD3PnHOgkIHI=; b=raPEv4sQl6MPyvbDj1Uci513A7Lraj41JDCKxv+yovMv59uhSHxQkqw/GkT+IOkL6AobFU NviyeWGhCzQVi0wJ5MciafeVXvFTyMGCXVSLbZfh4qm82kDRClCV5Gs9uSeduIPFuwkCQb SvZNzbkJyIfOcS6rmaoMkbtPpseI6LY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728077013; a=rsa-sha256; cv=none; b=7Cwag6Yh1ae78K8cJ9eO2z5WdSI9cLxKPras7KN6dM2PS9OJNwz3MW1TrmyJi9w0VHI+N6 ychZyIlSMrz65soyy8RXF2hsMFdosXyd8ZWNHPequo8O2Rb7687uyhDldAXjUZaHb6zhyn exHptmlI5Bo4YZjjEsGt3NFjycgtqIw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=FxvE+Uxp; spf=pass (imf07.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.171 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Fri, 4 Oct 2024 21:25:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1728077141; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cYKtCoATsBvcWFCPa9gSKY/ijfwd28CJD3PnHOgkIHI=; b=FxvE+UxpYBlx5VXP9BMFUDR0DbPw5dRg4ki38HZdOgHbyUHZOCjxs+3RCBzrk9Ul3dR6ES WCgCACAbUMJ96/3xlLzK18PATEwAjKsgYjN1+pCyQm+rqJ008fos8JS4p6WzI+g0NsqNib dzRBetNMBukPqAoUfVQf5oo1WKjAPeI= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Song Liu Cc: Namhyung Kim , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , LKML , bpf@vger.kernel.org, Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, Arnaldo Carvalho de Melo , Kees Cook Subject: Re: [PATCH v4 bpf-next 2/3] mm/bpf: Add bpf_get_kmem_cache() kfunc Message-ID: References: <20241002180956.1781008-1-namhyung@kernel.org> <20241002180956.1781008-3-namhyung@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D0DFE40004 X-Stat-Signature: yb9a5akb838botq9be1w1q4padjk4unw X-HE-Tag: 1728077143-735518 X-HE-Meta: U2FsdGVkX19FowHAjzGnopQd3Ph4Yw7NgwBFO3TMdB0LjdIBROZhUlfscn5gOeLw2zxBv3nDbtSyLZw/8kFTAeJdkqROsChteS8QqoPkge40FuCf1sLXyuCIbdhF15KjoIob0tpGg5FPkhwiJC2CUGN5t2lAO7nzQsmVsW12wq7XgdbvSbl5N+VfrPfbfigHmqtGUloESBo6biSXnZ4XKguGdUa+ZbNk+L6hNZmZr91VU18HUmWBVzLjatwjwk0mF1EHxuBDZuwBj8ShFaWCjJ6tYiK1YgkF/0LNlk0xwiE58IofLRRFGuHEBebtmCP1k/We8hRinOu8byl4Q/lnb4muLJ2XCy0H30RhxjQr4aAf7qMgBeWvmC/sRmaubI7Y0ivu/LMz2Ytb5FBptz/4B/gCv9ZTAaBb7mdlp86Yh6XkJ9ZUa/TOhvlEyuHS2HM9JfI+kRtaaJdvPdZ0jXEE2MJ2xeijdQF/ee5EDLu8n0r+msi7ddjAEbTDCRLPvh6TWEpsRbj4XA41kqvz7TXVbhPllTtryeRbEZvardwqkkjWX4d+QrDMY/t6KJfCdHDI9DM4qp2CyaU9kTugZjW8Js7k/vIhe2KH7NBnD7IeX2pOs7PW+7+uAOx5dWWFkMgniBGFjQrWPQoECWo5dpUtVEuvNjeWoAn5PIMM5EhYMWT3i/p1O/TvANrMlWQdJ3kOsQ6tbIicH8I2AjyIzqIozdTHfG5PLCk19erbHyYIkDWNzkSus32cTEIiQ3mpI+zSnTYfKxc4uZKL8vHOepAHTju4vvFBH7BeXpKPCscx5LquAVmOOlwXEUNK5ZGGNhstOjxIHtn+xBRx3Fs3lCcwveFyBgiWjd2oc4P4Mk1VSdsGkWWNj9HtRqovFwtIJ5oJqwrDB/nUxHd7fmm2Z2G6azz5Ht72lTmICtJObrJFSFYe38sX16fzQEiutFEoiIimILklBESJsYUbi4XE5/1 1LWG9NM0 MTldJVfUJnYHxgLfSEd9uoLv8ZPwmyR98aWAiyhHDz95Ct5glk4/Dmm/UBgZTCwRIrH/Q7VrNhwZnEpY+02pI+p2GzqZdq08Up32mOHrTO+qloZaICHxOMtcFjC0Cfo/Y+jypUKVnuA4sMa6o6xvZ7ZmhScnikfGAVnSJtBP10U5NUqvMb6ggXuNEvnFzdOzewZARxHFX3BCYCJhSSOGdSWCwtSOUgEL2IlzK92ok+SWKeT3VwuGadXumsUuFZyJleHMb6slLTBrJlng6kGnevMl8G+YdoOaDfbwfL6Yetd+bLsy1Un8/xKk6ZXN3UUhxon/nwQr2o7ulom7P9nQ4LhSO/NPnxI9lrBgw0cmvLmbLACJj1qUlATJKWQ5SRRYj11m8 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Oct 04, 2024 at 01:10:58PM -0700, Song Liu wrote: > On Wed, Oct 2, 2024 at 11:10 AM Namhyung Kim wrote: > > > > The bpf_get_kmem_cache() is to get a slab cache information from a > > virtual address like virt_to_cache(). If the address is a pointer > > to a slab object, it'd return a valid kmem_cache pointer, otherwise > > NULL is returned. > > > > It doesn't grab a reference count of the kmem_cache so the caller is > > responsible to manage the access. The intended use case for now is to > > symbolize locks in slab objects from the lock contention tracepoints. > > > > Suggested-by: Vlastimil Babka > > Acked-by: Roman Gushchin (mm/*) > > Acked-by: Vlastimil Babka #mm/slab > > Signed-off-by: Namhyung Kim > > --- > > kernel/bpf/helpers.c | 1 + > > mm/slab_common.c | 19 +++++++++++++++++++ > > 2 files changed, 20 insertions(+) > > > > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c > > index 4053f279ed4cc7ab..3709fb14288105c6 100644 > > --- a/kernel/bpf/helpers.c > > +++ b/kernel/bpf/helpers.c > > @@ -3090,6 +3090,7 @@ BTF_ID_FLAGS(func, bpf_iter_bits_new, KF_ITER_NEW) > > BTF_ID_FLAGS(func, bpf_iter_bits_next, KF_ITER_NEXT | KF_RET_NULL) > > BTF_ID_FLAGS(func, bpf_iter_bits_destroy, KF_ITER_DESTROY) > > BTF_ID_FLAGS(func, bpf_copy_from_user_str, KF_SLEEPABLE) > > +BTF_ID_FLAGS(func, bpf_get_kmem_cache, KF_RET_NULL) > > BTF_KFUNCS_END(common_btf_ids) > > > > static const struct btf_kfunc_id_set common_kfunc_set = { > > diff --git a/mm/slab_common.c b/mm/slab_common.c > > index 7443244656150325..5484e1cd812f698e 100644 > > --- a/mm/slab_common.c > > +++ b/mm/slab_common.c > > @@ -1322,6 +1322,25 @@ size_t ksize(const void *objp) > > } > > EXPORT_SYMBOL(ksize); > > > > +#ifdef CONFIG_BPF_SYSCALL > > +#include > > + > > +__bpf_kfunc_start_defs(); > > + > > +__bpf_kfunc struct kmem_cache *bpf_get_kmem_cache(u64 addr) > > +{ > > + struct slab *slab; > > + > > + if (!virt_addr_valid(addr)) > > + return NULL; > > + > > + slab = virt_to_slab((void *)(long)addr); > > + return slab ? slab->slab_cache : NULL; > > +} > > Do we need to hold a refcount to the slab_cache? Given > we make this kfunc available everywhere, including > sleepable contexts, I think it is necessary. It's a really good question. If the callee somehow owns the slab object, as in the example provided in the series (current task), it's not necessarily. If a user can pass a random address, you're right, we need to grab the slab_cache's refcnt. But then we also can't guarantee that the object still belongs to the same slab_cache, the function becomes racy by the definition.