[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPhsuW6ud21v2xz8iSXf=CiDL+R_zpQ+p8isSTMTw=EiJQtRSw@mail.gmail.com>
Date: Wed, 6 Nov 2024 15:04:12 -0800
From: Song Liu <song@...nel.org>
To: Juntong Deng <juntong.deng@...look.com>
Cc: Andrii Nakryiko <andrii.nakryiko@...il.com>, ast@...nel.org, daniel@...earbox.net,
john.fastabend@...il.com, andrii@...nel.org, martin.lau@...ux.dev,
eddyz87@...il.com, yonghong.song@...ux.dev, kpsingh@...nel.org,
sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org, memxor@...il.com,
snorcht@...il.com, brauner@...nel.org, bpf@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH bpf-next v3 0/4] bpf/crib: Add open-coded style process
file iterator and file related CRIB kfuncs
On Wed, Nov 6, 2024 at 2:49 PM Juntong Deng <juntong.deng@...look.com> wrote:
>
[...]
> >
> > CRIB is just one of possible applications of such kfuncs, so I'd steer
> > away from over-specifying it as CRIB.
> >
> > task_file open-coded iterator is generic, and should stay close to
> > other task iterator code, as you do in this revision.
> >
> > bpf_get_file_ops_type() is unnecessary, as we already discussed on v2,
> > __ksym and comparison is the way to go here.
> >
> > bpf_fget_task(), if VFS folks agree to add it, probably will have to
> > stay close to other similar VFS helpers.
> >
>
> Yes, I agree.
>
> Maybe we should put it in fs/bpf_fs_kfuncs.c?
fs/bpf_fs_kfuncs.c is a good place for bpf_fget_task().
Please note that currently all kfuncs in fs/bpf_fs_kfuncs.c are only
available to BPF LSM programs. We need to make some of them,
including bpf_fget_task, available to tracing functions.
Thanks,
Song
Powered by blists - more mailing lists