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 0FD5FCFC5E7 for ; Thu, 10 Oct 2024 17:04:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E6F46B0082; Thu, 10 Oct 2024 13:04:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7977A6B0083; Thu, 10 Oct 2024 13:04:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6606F6B0085; Thu, 10 Oct 2024 13:04:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 49AC86B0082 for ; Thu, 10 Oct 2024 13:04:40 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id AA0748091A for ; Thu, 10 Oct 2024 17:04:36 +0000 (UTC) X-FDA: 82658316678.05.13E17C6 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by imf17.hostedemail.com (Postfix) with ESMTP id 6EAD540004 for ; Thu, 10 Oct 2024 17:04:36 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OTnwRAW5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.43 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728579833; a=rsa-sha256; cv=none; b=f5w6lGf7ZfGLzsPiQkRf/sQIy12y+dFhd8ZzWYapuTgQaAlnzdhvHMH2hE4i93Y3ek8lYa YCT/hWuUJSQOGkPwstOPaPe9DH21GdbGUyutQB2h7ApTllgIpT3EzIQPHN1yNoGWmWDv7J RBe/9faoX3B0aWGeqfI/llY9e7xlITM= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OTnwRAW5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.43 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728579833; 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=c+DAWWUvKTQgW3MLl9vHnA8Jud2Bc9oa6MqljB4YdFk=; b=l1AIGWjneP+9MDKvLA18HukGGdJnsImDcrOgoFeG4okbF0tPHD5qhFkY/Me9qsBtKj0OeG foLC5+Om4yIijzwhiQNrxM9g791r7FMZq5bLSLWPGcS08dADpZsKYOzLq7hsP3pDf2JtZq qdbCqFlWNBwYD7fXDeGSLYgptQEJZcs= Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-37d518f9abcso259923f8f.2 for ; Thu, 10 Oct 2024 10:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728579876; x=1729184676; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=c+DAWWUvKTQgW3MLl9vHnA8Jud2Bc9oa6MqljB4YdFk=; b=OTnwRAW5xHMqNchCVda85kw2vZJAB1ZorCeQ/NftdNGCpMQnAEs6TXXCuSvfa7ZA/R MnfJm3SGTnX0obG6/Wb9aunor9yxAWTWOyIVJRX0bGlgI56xB4En3a2E+s1DWX1+jdF7 4b/7H6yQyW8BwXZqbQfHJQ85FqeKn3fgMfdQTcC+AToTK+l+YqQvJ+kedWZWi5jg315+ t09z2Q82dqsCAM4JvnVKM+3aeVwDQ6hU06sy5DVNPq/9qHtsBZGyrANbl7HL7ysG7wa8 xdwxpQvP+oLNwXzhQhbEmEEbFDRh0SqicRJka7qoK62TgSVE7Gk/wuzfF8//PzoYNCnO 1DjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728579876; x=1729184676; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=c+DAWWUvKTQgW3MLl9vHnA8Jud2Bc9oa6MqljB4YdFk=; b=Y/TDo5Rzqdg6jM3ETrjM7j6KThz6+QKd6nfNflq5ujQmLK+74A/6i4O1hwaJqcB5BR +SjXshJLYqZOUCcmzrowpVofIsuaWwM70Ces3w+oV2XQXQD5UBJ/YGk+DV27Vgf2JapR TsYIs4KDkSzXHAYvceD5mikVqULR6EfoFDBDjCT0b6paWJGJAoo/a3fZD1nX8wgDDYQr D+ZHmu+CPU8AREZ3nDjf+05+iIWNfq83I8GxbvC+t+RVfYW/Vs3iQOrkgqfyetbnXEf1 ymC64vj0/hQG+YBu64QnskNqd6vzypnfQxe2FkFdwvniRELnePbPVfxXFnieWFzzqln9 7bVA== X-Forwarded-Encrypted: i=1; AJvYcCUKCpFEpJsH4BBXfRvjGGBA4IC8m4SL4ingZxqQ9NjX7YwgbNYTKmGPwkrZIOfR+8fuLv5Z4QLwjg==@kvack.org X-Gm-Message-State: AOJu0Yxs2cUV+0gbNrAmJXcxp5km7nq0+Ys7Yv4dP107RlG7+Aer8/JP gsYQMQaryphtu7zj2DQaooHoFobduc6RkqaQMW8aLFGh5NyH7N0IAw/LIjQS6sOKvFmO9P1FnHe tl1+DoarRr9Jz166YdXu5K2+9Ius= X-Google-Smtp-Source: AGHT+IEClv/cTkt5E2SWxAPhIQ5PRwySBYvQxAVESe6/iRML/OaeVGWjqVj4NOlIkO5y/2r/8QROOzYWbH5DxUg6kZw= X-Received: by 2002:a05:6000:109:b0:37c:cdb6:6a9e with SMTP id ffacd0b85a97d-37d3a9b5242mr4815198f8f.9.1728579875879; Thu, 10 Oct 2024 10:04:35 -0700 (PDT) MIME-Version: 1.0 References: <20241002180956.1781008-1-namhyung@kernel.org> <20241002180956.1781008-3-namhyung@kernel.org> <37ca3072-4a0b-470f-b5b2-9828a2b708e5@suse.cz> In-Reply-To: From: Alexei Starovoitov Date: Thu, 10 Oct 2024 10:04:24 -0700 Message-ID: Subject: Re: [PATCH v4 bpf-next 2/3] mm/bpf: Add bpf_get_kmem_cache() kfunc To: Namhyung Kim 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 6EAD540004 X-Rspamd-Server: rspam01 X-Stat-Signature: 5gm84tnjjpagfs7tc8uwbwm1bc5mqbjm X-HE-Tag: 1728579876-415381 X-HE-Meta: U2FsdGVkX18qGTnwToDih2pd8HL/SuUvjAMPUufk5GIFT4gK2PfKJ3/hBZ2Pr3J9knO917LNAHns2gUpRquB4zlIXw26FFvwNaSAoHu7y3dwWGlPkOK5reEXlcgfn8MJDRZzvh93vw8dId2FBw2GkgR9fOx3x28z8Joj6iFd7F1C8eF/a1jcR4z572SlhlNU5rSoV47p+R0AQVRtlPAPqey/0KbQMRZNSCVhkP5pYDki3Ee++Py03QeDA92GT+gUabPtZ+VsYCZPVW347zZz69ebHmdzB86hdGJ8tdsX+vOKJu3j/eYfFezG5LcxZcpbnfwGbhk6EVz+3tH3pUcpIIA1d4UZd1DXGA/NxAMQlSN5jrW/IrK7kDqcOH3YM2af3p+IXD4PHjAkucc4A09xYchiSV9Y8IfjH0EZf19bbdn5zf3MXrS9FITkpm7zyxfBAO90/tTA/jgO/ZLYAoWde5VRFJAFBXIZM523K8Srnicf+6HuIiIFDXMPj6gHG8UBdGmcNQ0y1Z5VVQTIz3xMR1R5PiegGoqrbkEMFRoIO+/5D+FQp9E23kk3q++7f8B+OBvpgEjJRPG+5rbKnHJUJN1khCrpnox7MqyHOThJ5nq0TYqDxTRHe5gGcFOraanx2uPqA59CXVIAD1OsngaPeQho8VH3oL/qOKLbT8Nlcnce6tj2P8e/EcV2ZZbc8tVLd0ZmJd0RXCpruHsdaQOne5oLEMCW8qChFraGQJQHkFMyHZqQ5r0s+rv/TnclgzA3DtgcCJZxhzeovNwCVIx7Y4ARau/RKMgcdFEaIMbpdtGzEiNSnvk/L7b8r0KzyCoLNBFnL81CXPTMt8G7D80xuJXZ3X8zsyi4XPbiGNiPmUvAhixR/THx8XyHN9iZBREra+0VzGU/0XPPusxPnFZ5ygpb44iOkv2laiz4fxmobk+TrPyIg0EvWpXeI+JrpwtQNYWey15ZZHm12hLHFMP Earl/HGf ULHEx+Du6cD2EBOHNzoOUKZOp0K9YnSaSC6EV737gArgMMzNQ8NtQvfmQKehEbH1uYPkICi7KM1x0CI+5biqV6eQD6VOAPvVjxEYVjzZaOvOSjxDxTXmHGALiBWq69CBRq9JdKkHpBp7Hm1lstH3J2u+KujL4MWBBRcLLYdY7otXehrkajRPTuIJCILKNsGGIiKFHR/tAl2GrEHJeQZDKCvD0YZAOvKoA8Ow1LGaIxfwcCseuC80y7cemkxoWoMbBF0TcVfr2ubmNLy5yj2J96yKOvTSV5yEGGvsIcjI00sxAXK4TsBA0zA0OuPsv7+n9nKf3b+vj2aUg1hBx8k8xzMpE5MjgzZDQ6k7F+7bzBMD/3KWOLWF6MKTNAOcoTTSSV4BSysk35BKA10dHqW3k0rtYkBV/FNbVdTV9nzr7aKbQIwQNdFHuXOYhXjmTKuN446UoGklOrWn/VOrJwfqEDVw+3zkIDLIkV2NsneGTsB2jqS7At/++z/zw5GjWZ23jiQfTlH1K86+rFbWIgjn8ajKY+w== 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 9:46=E2=80=AFAM 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=E2=80=AFAM 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 pointe= r > > > >>> to a slab object, it'd return a valid kmem_cache pointer, otherwi= se > > > >>> 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 tracepoi= nts. > > > >>> > > > >>> 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 iterat= or > > > - 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 reco= rd > > > - after profiling itself, use the information in the maps from the fi= rst > > > 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_cach= e? > > > > > > 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 t= he > > > 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. 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.