On Fri, Apr 23, 2021 at 02:36:43PM -0700, Yonghong Song wrote: > > > > One thing that was not addressed from feedback is the name of new program type. > > Currently it's still: > > BPF_PROG_TYPE_SYSCALL, /* a program that can execute syscalls */ > > Do you have plan for other non-bpf syscalls? Maybe use the name > BPF_PROG_TYPE_BPF_SYSCALL? It will be really clear this is > the program type you can execute bpf syscalls. In this patch set it's already doing sys_bpf and sys_close syscalls :) > > > > The concern raised was that it sounds like a program that should be attached > > to a syscall. Like BPF_PROG_TYPE_KPROBE is used to process kprobes. > > I've considered and rejected: > > BPF_PROG_TYPE_USER - too generic > > BPF_PROG_TYPE_USERCTX - ambiguous with uprobes > > USERCTX probably not a good choice. People can write a program without > context and put the ctx into a map and use it. > > > BPF_PROG_TYPE_LOADER - ok-ish, but imo TYPE_SYSCALL is cleaner. > > User can write a program to do more than loading although I am not sure > how useful it is compared to implementation in user space. Exactly. Just BPF_PROG_TYPE_SYSCALL alone can be used as more generic equivalent to sys_close_range syscalls. If somebody needs to close a sparse set of FDs or get fd_to_be_closed from a map they can craft a bpf prog that would do that. Or if somebody wants to do a batched map processing... instead of doing sys_bpf() with BPF_MAP_UPDATE_BATCH they can craft a bpf prog. Plenty of use cases beyond LOADER. This patch set only allows BPF_PROG_TYPE_SYSCALL to be executed via prog_test_run, but I think it's safe to execute it upon entry to pretty much any syscall. So _SYSCALL suffix fits as both "a program that can execute syscalls" and as "a program that attaches to syscalls". The later is not implemented yet, but would fit right in.
