On Tue, Jun 3, 2025 at 1:50 PM Yonghong Song <yonghong.song@xxxxxxxxx> wrote:
>
>
>
> On 6/3/25 11:40 AM, Andrii Nakryiko wrote:
> > On Mon, Jun 2, 2025 at 11:59 PM Song Liu <song@xxxxxxxxxx> wrote:
> >> Introduce a path iterator, which reliably walk a struct path toward
> >> the root. This path iterator is based on path_walk_parent. A fixed
> >> zero'ed root is passed to path_walk_parent(). Therefore, unless the
> >> user terminates it earlier, the iterator will terminate at the real
> >> root.
> >>
> >> Signed-off-by: Song Liu <song@xxxxxxxxxx>
> >> ---
> >> kernel/bpf/Makefile | 1 +
> >> kernel/bpf/helpers.c | 3 +++
> >> kernel/bpf/path_iter.c | 58 ++++++++++++++++++++++++++++++++++++++++++
> >> kernel/bpf/verifier.c | 5 ++++
> >> 4 files changed, 67 insertions(+)
> >> create mode 100644 kernel/bpf/path_iter.c
> >>
> >> diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
> >> index 3a335c50e6e3..454a650d934e 100644
> >> --- a/kernel/bpf/Makefile
> >> +++ b/kernel/bpf/Makefile
> >> @@ -56,6 +56,7 @@ obj-$(CONFIG_BPF_SYSCALL) += kmem_cache_iter.o
> >> ifeq ($(CONFIG_DMA_SHARED_BUFFER),y)
> >> obj-$(CONFIG_BPF_SYSCALL) += dmabuf_iter.o
> >> endif
> >> +obj-$(CONFIG_BPF_SYSCALL) += path_iter.o
> >>
> >> CFLAGS_REMOVE_percpu_freelist.o = $(CC_FLAGS_FTRACE)
> >> CFLAGS_REMOVE_bpf_lru_list.o = $(CC_FLAGS_FTRACE)
> >> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> >> index b71e428ad936..b190c78e40f6 100644
> >> --- a/kernel/bpf/helpers.c
> >> +++ b/kernel/bpf/helpers.c
> >> @@ -3397,6 +3397,9 @@ BTF_ID_FLAGS(func, bpf_iter_dmabuf_next, KF_ITER_NEXT | KF_RET_NULL | KF_SLEEPAB
> >> BTF_ID_FLAGS(func, bpf_iter_dmabuf_destroy, KF_ITER_DESTROY | KF_SLEEPABLE)
> >> #endif
> >> BTF_ID_FLAGS(func, __bpf_trap)
> >> +BTF_ID_FLAGS(func, bpf_iter_path_new, KF_ITER_NEW | KF_SLEEPABLE)
> >> +BTF_ID_FLAGS(func, bpf_iter_path_next, KF_ITER_NEXT | KF_RET_NULL | KF_SLEEPABLE)
> >> +BTF_ID_FLAGS(func, bpf_iter_path_destroy, KF_ITER_DESTROY | KF_SLEEPABLE)
> >> BTF_KFUNCS_END(common_btf_ids)
> >>
> >> static const struct btf_kfunc_id_set common_kfunc_set = {
> >> diff --git a/kernel/bpf/path_iter.c b/kernel/bpf/path_iter.c
> >> new file mode 100644
> >> index 000000000000..0d972ec84beb
> >> --- /dev/null
> >> +++ b/kernel/bpf/path_iter.c
> >> @@ -0,0 +1,58 @@
> >> +// SPDX-License-Identifier: GPL-2.0-only
> >> +/* Copyright (c) 2025 Meta Platforms, Inc. and affiliates. */
> >> +#include <linux/bpf.h>
> >> +#include <linux/bpf_mem_alloc.h>
> >> +#include <linux/namei.h>
> >> +#include <linux/path.h>
> >> +
> >> +/* open-coded iterator */
> >> +struct bpf_iter_path {
> >> + __u64 __opaque[3];
> >> +} __aligned(8);
> >> +
> >> +struct bpf_iter_path_kern {
> >> + struct path path;
> >> + __u64 flags;
> >> +} __aligned(8);
> >> +
> >> +__bpf_kfunc_start_defs();
> >> +
> >> +__bpf_kfunc int bpf_iter_path_new(struct bpf_iter_path *it,
> >> + struct path *start,
> >> + __u64 flags)
> >> +{
> >> + struct bpf_iter_path_kern *kit = (void *)it;
> >> +
> >> + BUILD_BUG_ON(sizeof(*kit) > sizeof(*it));
> >> + BUILD_BUG_ON(__alignof__(*kit) != __alignof__(*it));
> >> +
> >> + if (flags) {
> >> + memset(&kit->path, 0, sizeof(struct path));
> >> + return -EINVAL;
> >> + }
> >> +
> >> + kit->path = *start;
> >> + path_get(&kit->path);
> >> + kit->flags = flags;
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +__bpf_kfunc struct path *bpf_iter_path_next(struct bpf_iter_path *it)
> >> +{
> >> + struct bpf_iter_path_kern *kit = (void *)it;
> >> + struct path root = {};
> >> +
> >> + if (!path_walk_parent(&kit->path, &root))
> >> + return NULL;
> >> + return &kit->path;
> >> +}
> >> +
> >> +__bpf_kfunc void bpf_iter_path_destroy(struct bpf_iter_path *it)
> >> +{
> >> + struct bpf_iter_path_kern *kit = (void *)it;
> >> +
> >> + path_put(&kit->path);
> > note, destroy() will be called even if construction of iterator fails
> > or we exhausted iterator. So you need to make sure that you have
> > bpf_iter_path state where you can detect that there is no path present
> > and skip path_put().
>
> In rare cases, it is possible &kit->path address could be destroyed
> and reused, right? Maybe we need more state in kit to detect the change?
kit->path is always referenced, so this should not happen.
Thanks,
Song
