Re: [RFC bpf-next] bpf: Fix perf bpf event and audit prog id logging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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);





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux