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 7384ACFB440 for ; Mon, 7 Oct 2024 12:57:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 682356B00D4; Mon, 7 Oct 2024 08:57:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 62F726B00D5; Mon, 7 Oct 2024 08:57:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D05A6B00D6; Mon, 7 Oct 2024 08:57:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 30AAF6B00D4 for ; Mon, 7 Oct 2024 08:57:16 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D57E31C622C for ; Mon, 7 Oct 2024 12:57:15 +0000 (UTC) X-FDA: 82646806830.04.1DF6831 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf13.hostedemail.com (Postfix) with ESMTP id 7F39820002 for ; Mon, 7 Oct 2024 12:57:12 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=VvvE12xu; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=XFPwfYxx; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=VvvE12xu; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=XFPwfYxx; spf=pass (imf13.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728305790; 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=DCnkUNp48eqK7B4xRBkDW7Ln7yGp8HpKJQU9fGxdJ6M=; b=OKWGPx4WciN8RTJBbS2ubVpGSezfO0D3vIS4H7iM/EWQYeqLiMtHweAfZ3x8ixCtyyFt/U U7yF4+xWpiJJ18dfJKHIkEzzipdzsw5oL1a5Yg6VXmsFrs4uFpoPLqhYdGqj75BkjXzLkF L/yEoCjMMxBpGByc8LR3k8B/rKAQQ+w= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=VvvE12xu; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=XFPwfYxx; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=VvvE12xu; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=XFPwfYxx; spf=pass (imf13.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728305790; a=rsa-sha256; cv=none; b=YjTPBnT9o7cSIXFu3blhpY0gZuYb7bOfKmvY1IOyg04gGVETvRTV5Mq/fCDzbOMDQBJ+7q lvvxsSaOhbm0m+8fqxU20R9318enMpR28K+loEk2iF6tCcH89j9gohz/QjWOVMGsUumhwX aDr+SrFwU0w1ePcgLRjKTKW9OS1VFKY= Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id BDBEC1FB49; Mon, 7 Oct 2024 12:57:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1728305830; h=from:from:reply-to: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=DCnkUNp48eqK7B4xRBkDW7Ln7yGp8HpKJQU9fGxdJ6M=; b=VvvE12xuoQF29aUeR/WqkgFw7joefpiN+oVKlr3KLVPmZ5F1UPn+030vk8h5DgEpCH8qDQ 4RZYZpaMb2z13fcvJJv+sxjtF20HxzXK80f4OSo6yrSYY0VJEdiO2Uxu3a2Fy0bpT/HFOB EIiT1LDC/UTNsX4HVdMjupqjmivOUVs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1728305830; h=from:from:reply-to: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=DCnkUNp48eqK7B4xRBkDW7Ln7yGp8HpKJQU9fGxdJ6M=; b=XFPwfYxxe1FsIcdwEyO8koKE0Rsq030fD8y4jvtTO3ehKoYqCdCXJS4QPVaihU3EAK+d/p IXvNaCwcnqQazMDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1728305830; h=from:from:reply-to: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=DCnkUNp48eqK7B4xRBkDW7Ln7yGp8HpKJQU9fGxdJ6M=; b=VvvE12xuoQF29aUeR/WqkgFw7joefpiN+oVKlr3KLVPmZ5F1UPn+030vk8h5DgEpCH8qDQ 4RZYZpaMb2z13fcvJJv+sxjtF20HxzXK80f4OSo6yrSYY0VJEdiO2Uxu3a2Fy0bpT/HFOB EIiT1LDC/UTNsX4HVdMjupqjmivOUVs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1728305830; h=from:from:reply-to: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=DCnkUNp48eqK7B4xRBkDW7Ln7yGp8HpKJQU9fGxdJ6M=; b=XFPwfYxxe1FsIcdwEyO8koKE0Rsq030fD8y4jvtTO3ehKoYqCdCXJS4QPVaihU3EAK+d/p IXvNaCwcnqQazMDw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 85669132BD; Mon, 7 Oct 2024 12:57:10 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id fTc4IKbaA2c/WwAAD6G6ig (envelope-from ); Mon, 07 Oct 2024 12:57:10 +0000 Message-ID: <37ca3072-4a0b-470f-b5b2-9828a2b708e5@suse.cz> Date: Mon, 7 Oct 2024 14:57:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 bpf-next 2/3] mm/bpf: Add bpf_get_kmem_cache() kfunc To: Roman Gushchin , 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 , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, Arnaldo Carvalho de Melo , Kees Cook References: <20241002180956.1781008-1-namhyung@kernel.org> <20241002180956.1781008-3-namhyung@kernel.org> From: Vlastimil Babka Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Stat-Signature: 4bpfcx81trgm4a5hm1xs1jpru3c6rap1 X-Rspamd-Queue-Id: 7F39820002 X-Rspamd-Server: rspam11 X-HE-Tag: 1728305832-197819 X-HE-Meta: U2FsdGVkX197aRVgLFIgp+VHKI8M+ah2cQrgek/oYXSWutJGe/VwzFEINw6gZeeCw83OwbODDCPlb0riNRR9j7hlDrR/V2MGilhlG81aXrs95vW2mgo+UXLC9rc5RXe2g5cUDwqX3hAwkUQkfbhxeNNHvaxC/iJYlpY0V9aAYE0ktreKTPHWmnqsMpIBdBcOpBBiuA882kfo0KaugPU8n6BQ/3xTGQ/uzSjebFZuz1PwXnU5svzpULSyjzTwWJMsU9AVsnch5ygSFaMicOLAtl1UnjLjBENa5zqyQ18PNlOCVHWDoiRTY5DQEBdj1uSvszsAj6Tc1LqmuWUJfaPQiFZ/e7fPH+QR9rCb5TxUUe6611/zpLuO5ODV1BZ4KJn2bttw8tfo5YsLHD5c1vBelKBVfghdDzU/YvjBfsqX43/gL63sUgg/0z+MZOWDV9g7zZ8Mx5iGytMmW7jaCGfig1gLpRBAjXcvkV4th/BNmJel09RW/oZRK5Z5k1TFpaJ+2b2VDgH5yGE/qnOzsnG0d8AeyTpN2rCuVPQhCh7PY26YrmhR4BJsatYeoygjELlVZtA3N4B78/892oTrgJNP0BZj0NY0g3JY/QzKwHhjDDU6kORZ6RRUrlR7RMGXz316NHXbWu6JNiHOw0eE7tD/b9h1uI3XDtOt+rfu/3heA+ufC0UUNVGpkmayHZM4wCLzhVL5JF5YmMQCPT0VBCuNuX1fwLy8kGXZH9BbxgDc+NZmpsuxK/zLjZkN8+GJpPinxJxmbfL/IGLv7TbSjYyaqGvDOTS+34OX7VeMXWGEEdxt4U8/etN0jfzZB20C8h7dM/EXCkaNxnsYX1mJp8bfEKEvvYmE6nF2K7kLSx0rzHZza/XUVBFeNt3/asjc9ZpLsx6rkHRAoR3z8LrAEQrcK8JJX4n58JA86ElgW8Ojg9uLM9mcSYRQTQXvSxXdY0FtfYkpMDfYGUzzCOcHIgh ZG9zSysf srpdgYRAa6qvG2poxqknZckVknewsGg1fmH9nRJR+Y0k2rhA2Tw6rxdl2Dj+7wWo5iyu5hO6ogFC3MAlJw4i755CAYLAQrLseL/2ABfQKyJo/N33aepDDYeGQ+yqduAM7nu7bakaMkkxhf8nVcBAl5CcZP3w6PS4GiKVmpeaUqZ/Ssd5l7O5XxsnPo4VMs1BRJn0FQBB2fEo9/Q5gQytnG6hL3vv0TzlFGBCdVHMkXWavglpWX2tZfTT2CQcw6LGa+Qdh18nKFDCVEmLRtW8kd3qeybWXPejVB1WImm0l8c1xtU97icN6/tH22I+SvEIqgMvLGFwVeLptFEfaXT7fCFu81eCEEc8NUd8kukb1raclqsCsEtu0FAVePYNPQzDaTgiITeKRe2Ef+DtRt7c26YHDFSzYQHwn7xpi4EKdwQnv916fT4GUGmj3Ebkwc1B2aJK8C9uqRPyxhT5jgrXT7wOFtMwppRFVTqKMBCxWj5xBQ7o= 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 10/4/24 11:25 PM, Roman Gushchin wrote: > 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 So IIRC from our discussions with Namhyung and Arnaldo at LSF/MM I thought the perf use case was: - at the beginning it iterates the kmem caches and stores anything of possible interest in bpf maps or somewhere - hence we have the iterator - during profiling, from object it gets to a cache, but doesn't need to access the cache - just store the kmem_cache address in the perf record - after profiling itself, use the information in the maps from the first step together with cache pointers from the second step to calculate whatever is necessary So at no point it should be necessary to take refcount to a kmem_cache? But maybe "bpf_get_kmem_cache()" is implemented here as too generic given the above use case and it should be implemented in a way that the pointer it returns cannot be used to access anything (which could be unsafe), but only as a bpf map key - so it should return e.g. an unsigned long instead? >>> --- >>> 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.