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).
As BPF_PROG_TYPE_SYSCALL becomes more general, it would be valuable to
make more kfuncs available for BPF_PROG_TYPE_SYSCALL.
