From: Namhyung Kim <namhyung@kernel.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
bpf <bpf@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Vlastimil Babka <vbabka@suse.cz>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
linux-mm <linux-mm@kvack.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Kees Cook <kees@kernel.org>,
"Paul E. McKenney" <paulmck@kernel.org>
Subject: Re: [PATCH v5 bpf-next 2/3] mm/bpf: Add bpf_get_kmem_cache() kfunc
Date: Tue, 15 Oct 2024 13:54:06 -0700 [thread overview]
Message-ID: <Zw7WbhSXnOlUf1lD@google.com> (raw)
In-Reply-To: <CAADnVQ+Y8BG80=8vcipKVnOL0Htd7W60f4LOPB5shG4eSORVcg@mail.gmail.com>
On Tue, Oct 15, 2024 at 11:25:11AM -0700, Alexei Starovoitov wrote:
> On Tue, Oct 15, 2024 at 11:20 AM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > On Mon, Oct 14, 2024 at 06:50:49PM -0700, Alexei Starovoitov wrote:
> > > On Mon, Oct 14, 2024 at 11:13 AM Namhyung Kim <namhyung@kernel.org> wrote:
> > > >
> > > > Hi Alexei,
> > > >
> > > > On Fri, Oct 11, 2024 at 12:14:14PM -0700, Namhyung Kim wrote:
> > > > > On Fri, Oct 11, 2024 at 11:35:27AM -0700, Alexei Starovoitov wrote:
> > > > > > On Thu, Oct 10, 2024 at 4:25 PM Namhyung Kim <namhyung@kernel.org> 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 returned point is marked as
> > > > > > > PTR_UNTRUSTED. And the kfunc has KF_RCU_PROTECTED as the slab object
> > > > > > > might be protected by RCU.
> > > > > >
> > > > > > ...
> > > > > > > +BTF_ID_FLAGS(func, bpf_get_kmem_cache, KF_RCU_PROTECTED)
> > > > > >
> > > > > > This flag is unnecessary. PTR_UNTRUSTED can point to absolutely any memory.
> > > > > > In this case it likely points to a valid kmem_cache, but
> > > > > > the verifier will guard all accesses with probe_read anyway.
> > > > > >
> > > > > > I can remove this flag while applying.
> > > > >
> > > > > Ok, I'd be happy if you would remove it.
> > > >
> > > > You will need to update the bpf_rcu_read_lock/unlock() in the test code
> > > > (patch 3). I can send v6 with that and Vlastimil's Ack if you want.
> > >
> > > Fixed all that while applying.
> > >
> > > Could you please follow up with an open-coded iterator version
> > > of the same slab iterator ?
> > > So that progs can iterate slabs as a normal for/while loop ?
> >
> > I'm not sure I'm following. Do you want a new test program to iterate
> > kmem_caches by reading list pointers manually? How can I grab the
> > slab_mutex then?
>
> No.
> See bpf_iter_task_new/_next/_destroy kfuncs and
> commit c68a78ffe2cb ("bpf: Introduce task open coded iterator kfuncs").
Oh, ok. Thanks for the pointer, I'll take a look and add the open code
version.
Thanks,
Namhyung
next prev parent reply other threads:[~2024-10-15 20:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-10 23:25 [PATCH v5 bpf-next 0/3] bpf: Add kmem_cache iterator and kfunc Namhyung Kim
2024-10-10 23:25 ` [PATCH v5 bpf-next 1/3] bpf: Add kmem_cache iterator Namhyung Kim
2024-10-11 18:33 ` Alexei Starovoitov
2024-10-11 19:13 ` Namhyung Kim
2024-10-11 18:44 ` Alexei Starovoitov
2024-10-11 19:41 ` Andrii Nakryiko
2024-10-11 19:43 ` Andrii Nakryiko
2024-10-14 15:25 ` Vlastimil Babka
2024-10-10 23:25 ` [PATCH v5 bpf-next 2/3] mm/bpf: Add bpf_get_kmem_cache() kfunc Namhyung Kim
2024-10-11 18:35 ` Alexei Starovoitov
2024-10-11 19:14 ` Namhyung Kim
2024-10-14 18:13 ` Namhyung Kim
2024-10-15 1:50 ` Alexei Starovoitov
2024-10-15 18:19 ` Namhyung Kim
2024-10-15 18:25 ` Alexei Starovoitov
2024-10-15 20:54 ` Namhyung Kim [this message]
2024-10-10 23:25 ` [PATCH v5 bpf-next 3/3] selftests/bpf: Add a test for kmem_cache_iter Namhyung Kim
2024-10-15 2:00 ` [PATCH v5 bpf-next 0/3] bpf: Add kmem_cache iterator and kfunc patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zw7WbhSXnOlUf1lD@google.com \
--to=namhyung@kernel.org \
--cc=42.hyeyoo@gmail.com \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cl@linux.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kees@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=martin.lau@linux.dev \
--cc=paulmck@kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=vbabka@suse.cz \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.