On 6/8/21 12:51 PM, Kenny Ho wrote:
On Fri, Jun 4, 2021 at 4:47 PM Kenny Ho <y2kenny@xxxxxxxxx> wrote:
On Fri, Jun 4, 2021 at 12:11 PM Yonghong Song <yhs@xxxxxx> wrote:
On 6/3/21 11:13 PM, Martin KaFai Lau wrote:
Making the kfunc call whitelist more accessible is useful in general.
The bpf tcp-cc struct_ops is the only prog type supporting kfunc call.
What is your use case to introspect this whitelist?
Agree. It would be good if you can share your use case.
At the high level, I am trying to see if we can use bpf in the drm
subsystem and gpu drivers which are kernel modules. My initial
motivation was to use bpf for dynamic/run-time reconfiguration of the
drm/gpu driver (for experimentation.) But now that I learned more
about bpf, I think there are quite a few more things I can do with it.
(Debugging during GPU hw bring-ups, profiling driver performance in
live system, etc.) I have been looking into bpf with kprobe and
struct_ops.
In terms of kernel module support for bpf/btf, Andrii told me about it
last year and I see that his feature is in (I was able to do a btf
dump file for /sys/kernel/btf/amdgpu, /sys/kernel/btf/drm_ttm_helper,
for example.) The next thing I thought about was having helper
functions from kernel modules and Toke pointed me to Martin's patch
around "unstable helpers"/calling whitelisted kernel functions and
this is where we are at.
Yonghong and Martin, does the use case make sense? Or am I trying to
do something stupid?
So your intention is to call functions in
drivers/gpu/drm/drm_gem_ttm_helper.c, right? How do you get function
parameters? What kinds of programs you intend to call
this functions?
kprobe probably won't work as kernel does not capture
traced function types. fentry program might be a good
choice.
if you can *craft* a bpf program to show how
kernel function is used that will be great. We will
then see how verifier can help enforce safety.
Kenny
