From: Teng Qi <starmiku1207184332@xxxxxxxxx> Hi, bpf developers, We are developing a static tool to check the matching between helpers and the context of hooks. During our analysis, we have discovered some important findings that we would like to report. ‘kernel/bpf/syscall.c: 2097 __bpf_prog_put()’ shows that function bpf_prog_put_deferred() won`t be called in the condition of ‘in_irq() || irqs_disabled()’. if (in_irq() || irqs_disabled()) { INIT_WORK(&aux->work, bpf_prog_put_deferred); schedule_work(&aux->work); } else { bpf_prog_put_deferred(&aux->work); } We suspect this condition exists because there might be sleepable operations in the callees of the bpf_prog_put_deferred() function: kernel/bpf/syscall.c: 2097 __bpf_prog_put() kernel/bpf/syscall.c: 2084 bpf_prog_put_deferred() kernel/bpf/syscall.c: 2063 __bpf_prog_put_noref() kvfree(prog->aux->jited_linfo); kvfree(prog->aux->linfo); Additionally, we found that array prog->aux->jited_linfo is initialized in ‘kernel/bpf/core.c: 157 bpf_prog_alloc_jited_linfo()’: prog->aux->jited_linfo = kvcalloc(prog->aux->nr_linfo, sizeof(*prog->aux->jited_linfo), bpf_memcg_flags(GFP_KERNEL | __GFP_NOWARN)); Our question is whether the condition 'in_irq() || irqs_disabled() == false' is sufficient for calling 'kvfree'. We are aware that calling 'kvfree' within the context of a spin lock or an RCU lock is unsafe. Therefore, we propose modifying the condition to include in_atomic(). Could we update the condition as follows: "in_irq() || irqs_disabled() || in_atomic()"? Thank you! We look forward to your feedback. Signed-off-by: Teng Qi <starmiku1207184332@xxxxxxxxx>