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 A19E9D2444F for ; Thu, 10 Oct 2024 22:56:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 27C706B0083; Thu, 10 Oct 2024 18:56:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 22CF86B0088; Thu, 10 Oct 2024 18:56:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F4A86B0089; Thu, 10 Oct 2024 18:56:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E5D2C6B0083 for ; Thu, 10 Oct 2024 18:56:43 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id AC5791403C8 for ; Thu, 10 Oct 2024 22:56:39 +0000 (UTC) X-FDA: 82659203844.14.B2443F2 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf08.hostedemail.com (Postfix) with ESMTP id 3B91916001F for ; Thu, 10 Oct 2024 22:56:40 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=kRbt76lN; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of namhyung@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=namhyung@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728600973; a=rsa-sha256; cv=none; b=bxUT9TjIzQ8PIGUC9Ni+BhbhF2Zf29FZhcrCOAK55drF5G+ew0KI51Gn/l+xpdYGBnK75u eGc31HxtX1bmen/Bjkevcn/hvuOtFyCobf4mZAZp07T4HfMH4zLi7O8LGUnMblCGUPjS3Z 5pnr/xqF1LyAscTcZtAsSlBu6plQB08= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=kRbt76lN; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of namhyung@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=namhyung@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728600973; 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=EaVElchat/V5CQhSn2W7b6wiJDESU+WYJleGUXA8auA=; b=bwOgKGgYjRk4XgoUdentnrwhTJV5nNLZ2TLdYJliVaFaYzesBTFr0WL+L7korGA8eh8MY7 3rDkGRcOmK9z12V7pKECII4osq6W0a11Bi7uz4ksp3QNrBuVfXGdUtIyo1BFXY2QajVfRI 4PjTCXL579jV7ZNVFVxeVtNSf2BjhaA= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 1E5BCA44D0B; Thu, 10 Oct 2024 22:56:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94DDAC4CEC5; Thu, 10 Oct 2024 22:56:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728601000; bh=S0gsjnawtQCm9QTdFF7z0fX/jdedpHOu7Gvko5BM2YI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kRbt76lNthqIjZaczXutLVF3+ryQvMPukms0RG7RvHK1oSsfHbSq0GOMcJR5aCqNh dpU+o0y13D/BLhiV7RCxbh99qlf05DB7aXXHYFmLdYJ0yDWvZ7Rk5ziWXkWKMcCroM IEs92G2llaOOarLsK1xbRPvTI7tKCdxy0XvEPdoDSqASvIV7GCc5fUWtBbZGM29wFQ JR9JpOBkRA4QdohJu5/rWBpqXgzafig0AhdQ2pyGlEsdwNf/oQsRjskwnlOKc3eaOf Iag8+sMv1B/CdlT+tNFV2oD1jGaIRcfPwqh4WyN8J5VH77DqlpL/DR2Zp7nXwhh/27 /Aal1ZgZPnvxg== Date: Thu, 10 Oct 2024 15:56:38 -0700 From: Namhyung Kim To: Alexei Starovoitov Cc: Vlastimil Babka , Roman Gushchin , Song Liu , 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 , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm , 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> <37ca3072-4a0b-470f-b5b2-9828a2b708e5@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Stat-Signature: 8re6bprdbnf7yz9p59giqp1wjhfu4t8e X-Rspamd-Queue-Id: 3B91916001F X-Rspamd-Server: rspam02 X-HE-Tag: 1728601000-8053 X-HE-Meta: U2FsdGVkX1/BF8EAJmS9OlvSuB8pivfTeqeC3H9gqKXPmWPbTvEz1bipk632Q3NwXg/RV8lEh8aJFukwMPxyeS9k2TUozlzg6xkyOSUPFQckh50wXxEKdaXSHvIFG6Emds9IrtLSYWKN8+8UBTF35yRt2YArvRqYBTUUk6AnmofdaRwmPBnRrRiW7AbKvCEF7UWmyC0kXW/KmWnduKZJ9itVybOkg5tKGLr11rzpjA4/rE7g4FCtW8bBSjooTeKWWbTrwF9qmJOaRuqq1cYoxYq+TGgTPSh510zZcoqFR0E9Olu8qaNdmzpSan1rdGlmhO/LOKG317Q1iKKw/WTeWl8XY8R01Snb15XVsoUvuZmKX4xWF1NwqmEvdOy8mhYl+I0U2/nqEBn1apQzBDNNEz/NXR9vYzAZsh5ZvmsdvBIcpKkvkcCQcvWJHWC8y9m5hmL1DRJZmWcGX+IE6IBGpOGQyQj2OpCmHbMddFmjbdsL5IJzPGfwhQ39Ug7jfS5YWSnVEeDB74+s+pTzs2yghFwq7SLIy2huzPgx0ELS2jpn3cx7gHjpBjrCQ/i5fT194IXzWpyOSeGrEHNaw9aiK+KeQELrNcrYfxHifqLT+L2ORr+DDGJCpyP/78EN3wqjQJbNvXfCLoNjF33SX980j/HtbJdDnhulpG74AMvY1gXlbfMCKb2iBxsi6uI3rqkybpS2df5vpaFvYl+Irfo8v+4mPSIRs5udLHOgpmc0jCiSPQ7OK/w+X+EavGD43bmo/A//N67MhVEP798762o3g0zrcMg90sECXR3O88ZrSFpLogiWRHmvSBPj7rh9pd3ZQNnNRsN86jxgIVnMdzSK4wxJnbMQIGZ8KGsj1hBpS8mVfs4IyjOJRbN6TZ11Sy4K/L50wUfQEBhfCpzA4SS0JVT4aQafAkeq6VdnFPwYCoouZhhc0VCEvHBW1tFDkMRZWFnP/aoC/80v3n922kc /IFkSFP5 4AfTA6FeSK5Khs9DxXKfXOi2kgaPP32y/PozbyVMNys1oCam9Hdpn92IGvLLaQ9H9R37NoCsnR2/hopcZFHj1OIF4h7UW97yylQuuuF2Zu6ot6tWCMEg0W30QABfEWRcGhqntDTyGg5TNt28PM0o9sHlJMhUuhJFwVDkW6GJ0lZMrQ2a7vNR3D2zX9kGLboZHaL/thQI/aKyQDYXvmgi6MlmZvMCNr1ZtF4tAk6T0RzZVwXRemFb2JqTtNiuBqpWelO3DP7mPJqyKu8SEvbTqGYrDG1l2GdAZO046yz0jZoDzXWR0AzmuYokgckyGg78Hm5Nb+Mz+eH4Ln/0OkotIcTMvg53ml5c5AyHPZtWmvWzNuzmy1PSFGHtsb7pnqknibHShAPpiURAWEJeruqX9xwYBi258meuDiWdhYBNRGKZNkb+hgrEueal3KZFQDdjQT8ZJXsTZc72esc0= 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 Thu, Oct 10, 2024 at 10:04:24AM -0700, Alexei Starovoitov wrote: > On Thu, Oct 10, 2024 at 9:46 AM Namhyung Kim wrote: > > > > On Wed, Oct 09, 2024 at 12:17:12AM -0700, Namhyung Kim wrote: > > > On Mon, Oct 07, 2024 at 02:57:08PM +0200, Vlastimil Babka wrote: > > > > 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 > > > > > > Correct. > > > > > > > > > > > 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? > > > > > > Yep, this should work for my use case. Maybe we don't need the > > > iterator when bpf_get_kmem_cache() kfunc returns the valid pointer as > > > we can get the necessary info at the moment. But I think it'd be less > > > efficient as more work need to be done at the event (lock contention). > > > It'd better setting up necessary info in a map before monitoring (using > > > the iterator), and just looking up the map with the kfunc while > > > monitoring the lock contention. > > > > Maybe it's still better to return a non-refcounted pointer for future > > use. I'll leave it for v5. > > Pls keep it as: > __bpf_kfunc struct kmem_cache *bpf_get_kmem_cache(u64 addr) > > just make sure it's PTR_UNTRUSTED. Sure, will do. > No need to make it return long or void *. > The users can do: > bpf_core_cast(any_value, struct kmem_cache); > anyway, but it would be an unnecessary step. Yeah I thought there would be a way to do that. Thanks, Namhyung