On 11/15/22 10:50 AM, Jiri Olsa wrote:
hi,
perf_event_bpf_event and bpf_audit_prog calls currently report zero
program id for unload path.
It's because of the [1] change moved those audit calls into work queue
and they are executed after the id is zeroed in bpf_prog_free_id.
I originally made a change that added 'id_audit' field to struct
bpf_prog, which would be initialized as id, untouched and used
in audit callbacks.
Then I realized we might actually not need to zero prog->aux->id
in bpf_prog_free_id. It seems to be called just once on release
paths. Tests seems ok with that.
thoughts?
thanks,
jirka
[1] d809e134be7a ("bpf: Prepare bpf_prog_put() to be called from irq context.")
---
kernel/bpf/syscall.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index fdbae52f463f..426529355c29 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -1991,7 +1991,6 @@ void bpf_prog_free_id(struct bpf_prog *prog, bool do_idr_lock)
__acquire(&prog_idr_lock);
idr_remove(&prog_idr, prog->aux->id);
- prog->aux->id = 0;
This would trigger a race when offloaded progs are used, see also ad8ad79f4f60 ("bpf:
offload: free program id when device disappears"). __bpf_prog_offload_destroy() calls
it, and my read is that later bpf_prog_free_id() then hits the early !prog->aux->id
return path. Is there a reason for irq context to not defer the bpf_prog_free_id()?
if (do_idr_lock)
spin_unlock_irqrestore(&prog_idr_lock, flags);
