Re: [PATCH bpf-next v5 4/5] bpf: Make fs kfuncs available for SYSCALL and TRACING program types

[Juntong Deng]

On 2024/12/11 22:06, Song Liu wrote:
> On Wed, Dec 11, 2024 at 1:29 PM Juntong Deng <juntong.deng@xxxxxxxxxxx> wrote:
> > On 2024/12/10 18:58, Alexei Starovoitov wrote:
> > > On Tue, Dec 10, 2024 at 6:43 AM Christian Brauner <brauner@xxxxxxxxxx> wrote:
> > > > On Tue, Dec 10, 2024 at 02:03:53PM +0000, Juntong Deng wrote:
> > > > > Currently fs kfuncs are only available for LSM program type, but fs
> > > > > kfuncs are generic and useful for scenarios other than LSM.
> > > > >
> > > > > This patch makes fs kfuncs available for SYSCALL and TRACING
> > > > > program types.
> > > >
> > > > I would like a detailed explanation from the maintainers what it means
> > > > to make this available to SYSCALL program types, please.
> > >
> > > Sigh.
> > > This is obviously not safe from tracing progs.
> > >
> > >   From BPF_PROG_TYPE_SYSCALL these kfuncs should be safe to use,
> > > since those progs are not attached to anything.
> > > Such progs can only be executed via sys_bpf syscall prog_run command.
> > > They're sleepable, preemptable, faultable, in task ctx.
> > >
> > > But I'm not sure what's the value of enabling these kfuncs for
> > > BPF_PROG_TYPE_SYSCALL.
> >
> > Thanks for your reply.
> >
> > Song said here that we need some of these kfuncs to be available for
> > tracing functions [0].
>
> I meant we can put the new kfuncs, such as bpf_get_file_ops_type, in
> bpf_fs_kfuncs.c, and make it available to tracing programs. But we
> cannot blindly make all of these kfuncs available to tracing programs.
> Instead, we need to review each kfunc and check whether it is safe
> for tracing programs.
>
> Thanks,
> Song

Thanks for joining the discussion.

Yes, we should do that.

Sorry for the misunderstanding.

> > If Song saw this email, could you please join the discussion?
> >
> > [0]:
> > https://lore.kernel.org/bpf/CAPhsuW6ud21v2xz8iSXf=CiDL+R_zpQ+p8isSTMTw=EiJQtRSw@xxxxxxxxxxxxxx/