On 2024/12/12 00:53, Alexei Starovoitov 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].
If Song saw this email, could you please join the discussion?
[0]:
https://lore.kernel.org/bpf/CAPhsuW6ud21v2xz8iSXf=CiDL+R_zpQ+p8isSTMTw=EiJQtRSw@xxxxxxxxxxxxxx/
For BPF_PROG_TYPE_SYSCALL, I think BPF_PROG_TYPE_SYSCALL has now
exceeded its original designed purpose and has become a more general
program type.
Currently BPF_PROG_TYPE_SYSCALL is widely used in HID drivers, and there
are some use cases in sched-ext (CRIB is also a use case, although still
in infancy).
hid switched to use struct_ops prog type.
I believe syscall prog type in hid is a legacy code.
Those still present might be leftovers for older kernels.
sched-ext is struct_ops only. No syscall progs there.
I saw some on Github [0], sorry, yes they are not in the Linux tree.
[0]:
https://github.com/search?q=repo%3Asched-ext%2Fscx%20SEC(%22syscall%22)&type=code
As BPF_PROG_TYPE_SYSCALL becomes more general, it would be valuable to
make more kfuncs available for BPF_PROG_TYPE_SYSCALL.
Maybe. I still don't understand how it helps CRIB goal.
For CRIB goals, the program type is not important. What is important is
that CRIB bpf programs are able to call the required kfuncs, and that
CRIB ebpf programs can be executed from userspace.
In our previous discussion, the conclusion was that we do not need a
separate CRIB program type [1].
BPF_PROG_TYPE_SYSCALL can be executed from userspace via prog_run, which
fits the CRIB use case of calling the ebpf program from userspace to get
process information.
So BPF_PROG_TYPE_SYSCALL becomes an option.
[1]:
https://lore.kernel.org/bpf/etzm4h5qm2jhgi6d4pevooy2sebrvgb3lsa67ym4x7zbh5bgnj@feoli4hj22so/
In fs/bpf_fs_kfuncs.c, CRIB currently needs bpf_fget_task (dump files
opened by the process), bpf_put_file, and bpf_get_task_exe_file.
So I would like these kfuncs to be available for BPF_PROG_TYPE_SYSCALL.
bpf_get_dentry_xattr, bpf_get_file_xattr, and bpf_path_d_path have
nothing to do with CRIB, but they are all in bpf_fs_kfunc_set_ids.
Should we make bpf_fs_kfunc_set_ids available to BPF_PROG_TYPE_SYSCALL
as a whole? Or create a separate set? Maybe we can discuss.
